Aplicar sistemas de engenharia de software

Artigo
07/25/2024

Melhorar o autoatendimento do desenvolvedor deve ser um dos primeiros problemas que você enfrenta em sua jornada de engenharia de plataforma.

Uma das maneiras mais fáceis de começar a habilitar experiências automatizadas de autoatendimento é reutilizar seus sistemas de engenharia existentes. Esses sistemas não são apenas familiares para você e seus clientes internos, mas também podem permitir uma ampla variedade de cenários de automação, mesmo que a experiência inicial do usuário não seja bonita.

Este artigo fornece dicas para aplicar seus sistemas de engenharia para lidar com uma variedade mais ampla de cenários de autoatendimento e detalhes sobre como encapsular as práticas recomendadas em modelos que ajudam você a começar e permanecer certo.

Avalie suas práticas básicas de DevOps e DevSecOps

Os sistemas de engenharia são um aspecto crítico da sua plataforma interna de desenvolvedor. As plataformas internas de desenvolvedor são construídas a partir dos principais locatários de DevOps e DevSecOps para reduzir a carga cognitiva para todos os envolvidos.

O DevOps combina desenvolvimento e operações para unir pessoas, processos e tecnologia no planejamento, desenvolvimento, entrega e operações de aplicativos. O objetivo é melhorar a colaboração entre funções historicamente isoladas, como desenvolvimento, operações de TI, engenharia de qualidade e segurança. Você estabelece um loop contínuo entre desenvolvimento, implantação, monitoramento, observação e comentários. O DevSecOps se encaixa nesse loop com práticas de segurança contínuas em todo o processo de desenvolvimento de aplicativos.

Imagem do ciclo de vida do DevOps com planejamento, entrega, desenvolvimento, operação.

As seções a seguir se concentram em melhorias mais diretamente atribuídas ao movimento de engenharia de plataforma: caminhos pavimentados, provisionamento automatizado de infraestrutura (além da implantação de aplicativos), configuração do ambiente de codificação, juntamente com provisionamento de autoatendimento e configuração de ferramentas, ativos de equipe e serviços que não fazem parte diretamente do loop de desenvolvimento de aplicativos.

Estabeleça os caminhos pavimentados desejados

Se você já possui vários conjuntos de ferramentas que compõem seus sistemas de engenharia, uma decisão inicial a ser tomada é se deseja consolidá-los como parte de seus esforços iniciais de engenharia de plataforma ou se oferecerá suporte a uma constelação de ferramentas diferentes desde o início. Definir um conjunto de caminhos pavimentados dentro dessa constelação de ferramentas é mais eficaz e fornece um maior nível de flexibilidade.

À medida que você começa a mudar para uma mentalidade de produto, pense nos sistemas de engenharia dentro desses caminhos pavimentados como consistindo em ferramentas que são gerenciadas centralmente como um serviço para as equipes de desenvolvimento. Equipes ou divisões individuais dentro de sua organização podem se desviar, mas deverão gerenciar, manter e pagar por suas ferramentas separadamente, ao mesmo tempo em que aderem a quaisquer requisitos de conformidade. Isso fornece uma maneira de alimentar novas ferramentas no ecossistema sem interrupções, pois você pode avaliar qualquer coisa que se desvie para possível inclusão em um caminho pavimentado ao longo do tempo. Como disse um líder de engenharia de plataforma:

Você ainda pode fazer suas próprias coisas, mas fazê-lo na direção que estamos indo... Você pode mudar o que quiser, mas isso se torna sua responsabilidade. Você é o dono das mudanças - você é o dono das facas afiadas. - Mark, líder de engenharia de plataforma, grande empresa multinacional europeia de varejo

Dado que um dos principais objetivos da engenharia de plataforma é mudar para uma mentalidade de produto em que você agrega valor aos seus clientes internos, essa abordagem de constelação normalmente funciona melhor do que um mandato de cima para baixo. À medida que você estabelece e refina seus caminhos pavimentados, deixar alguma flexibilidade permite que as equipes forneçam informações e atendam a quaisquer requisitos verdadeiramente exclusivos para um determinado aplicativo sem afetar outras pessoas na organização. Isso leva a um conjunto de caminhos dourados totalmente pavimentados, enquanto outros são apenas parcialmente pavimentados. Nos casos em que não há requisitos exclusivos, o trabalho extra que as equipes de desenvolvimento assumem naturalmente fará com que elas queiram mudar para um caminho com suporte ao longo do tempo.

Se você preferir uma estratégia de consolidação, a migração de aplicativos existentes pode ser mais trabalhosa do que o esperado, portanto, para começar, você provavelmente desejará se concentrar no aspecto inicial correto desse espaço e se concentrar em novos projetos. Isso lhe dá seu primeiro caminho pavimentado, enquanto tudo o que existe é inerentemente não pavimentado. As equipes de desenvolvimento no caminho não pavimentado considerarão a mudança assim que seu novo caminho pavimentado mostrar seu valor para a organização. Nesse ponto, você pode executar uma campanha para acertar para colocar todos no estado desejado por meio de comunicação bidirecional, pois as equipes de desenvolvimento veem isso como um benefício e não como um imposto. Durante a campanha, as equipes de engenharia de plataforma podem se concentrar em ajudar as equipes a migrar, enquanto as equipes de desenvolvimento fornecem feedback sobre como melhorar os caminhos pavimentados.

Independentemente disso, evite exigir o uso de seus caminhos pavimentados. A maneira mais eficaz de implementar caminhos pavimentados é enfatizar o que as equipes ganham com eles, em vez de por meio da adoção forçada. Como sua plataforma interna de desenvolvedor se concentra em deixar essas mesmas equipes felizes, a pressão sobre o orçamento e o tempo de retorno sobre os líderes individuais cuidam do resto. As campanhas Get Right fornecem um caminho para conversas bidirecionais sobre a melhor maneira para aqueles que estão em um caminho não pavimentado mudarem.

Use ferramentas de automação do desenvolvedor para melhorar o autoatendimento para seus caminhos pavimentados

Parte da criação de seu primeiro caminho pavimentado deve ser estabelecer seus principais produtos de automação de desenvolvedor. Eles são importantes quando você começa a pensar em habilitar os recursos de autoatendimento do desenvolvedor.

Habilite o provisionamento automático da infraestrutura de aplicativos durante a entrega contínua

Se ainda não tiver sido implementado, os problemas identificados durante o planejamento provavelmente apontarão para problemas que a integração contínua (CI) e a entrega contínua (CD) podem ajudar a resolver. Produtos como GitHub Actions, Azure DevOps, Jenkins, juntamente com soluções GitOps baseadas em pull, como Flux ou Argo CD , existem neste espaço. Você pode começar a usar esses tópicos no centro de recursos do Microsoft DevOps.

Mesmo que você já tenha implementado uma maneira de implantar continuamente seu aplicativo na infraestrutura existente, considere o uso da IaC (infraestrutura como código ) para criar ou atualizar a infraestrutura de aplicativo necessária como parte do pipeline de CD.

Por exemplo, considere estas ilustrações que mostram duas abordagens que usam GitHub Actions para atualizar a infraestrutura e implantar no Serviço de Kubernetes do Azure: uma usando implantações baseadas em push e outra implantações baseadas em pull (GitOps).

A escolha é orientada pelo seu conjunto de habilidades de IaC existente e pelos detalhes da plataforma de aplicativos de destino. A abordagem GitOps é mais recente e popular entre as organizações que usam o Kubernetes como base para seus aplicativos, enquanto o modelo baseado em pull atualmente oferece mais flexibilidade, dado o número de opções disponíveis para ele. Esperamos que a maioria das organizações use uma combinação dos dois. Independentemente disso, tornar-se bem versado nas práticas de IaC ajudará você a aprender padrões que se aplicam a outros cenários de automação.

Centralize a IaC em um catálogo ou registro para dimensionar e melhorar a segurança

Para gerenciar e dimensionar a IaC entre aplicativos, você deve publicar seus artefatos de IaC centralmente para reutilização. Por exemplo, você pode usar módulos do Terraform em um registro, módulos Bicep, receitas do Radius ou Gráficos do Helm armazenados em um registro de Artefato do OCI nativo da nuvem, como o ACR (Registro de Contêiner do Azure), o DockerHub ou o catálogo no ADE (Ambientes de Implantação do Azure). Para GitOps e Kubernetes, a API de Cluster (e implementações como CAPZ) pode permitir que você gerencie clusters de carga de trabalho do Kubernetes, enquanto definições de recursos personalizados, como o Operador de Serviço do Azure, podem fornecer suporte adicional para outros tipos de recursos do Azure, outras ferramentas, como recursos de suporte Crossplane em várias nuvens. Eles permitem que você use gráficos do Helm centralizados ou comuns em algo como o ACR para uma variedade mais ampla de cenários.

A centralização da IaC melhora a segurança, dando a você um melhor controle sobre quem pode fazer atualizações, pois elas não são mais armazenadas com o código do aplicativo. Há menos risco de uma interrupção acidental causada por uma alteração inadvertida durante uma atualização de código quando especialistas, operações ou engenheiros de plataforma fazem as alterações necessárias. Os desenvolvedores também se beneficiam desses blocos de construção, pois não precisam criar modelos de IaC completos e se beneficiam automaticamente das práticas recomendadas codificadas.

O formato de IaC escolhido depende do conjunto de habilidades existente, do nível de controle necessário e do modelo de aplicativo usado. Por exemplo , os Aplicativos de Contêiner do Azure (ACA) e o recente projeto experimental de incubação do Radius OSS são mais opinativos do que usar o Kubernetes diretamente, mas também simplificam a experiência do desenvolvedor. O módulo de treinamento Descrever tipos de serviço de nuvem pode ajudá-lo a entender os prós e contras de diferentes modelos. Independentemente disso, referenciar a IaC centralizada e gerenciada em vez de ter definições completas em sua árvore de origem traz benefícios significativos.

Persistir quaisquer identidades ou segredos de provisionamento necessários de forma que os desenvolvedores não possam acessá-los diretamente nas camadas dos blocos de construção básicos para governança. Por exemplo, considere esta ilustração sobre a separação de funções que você pode obter usando o ADE (Ambientes de Implantação do Azure).

Aqui, engenheiros de plataforma e outros especialistas desenvolvem IaC e outros modelos e os colocam em um catálogo. As operações podem adicionar identidades e assinaturas gerenciadas por "tipo de ambiente" e atribuir desenvolvedores e outros usuários que têm permissão para usá-las para provisionamento.

Os desenvolvedores ou seu pipeline de CI/CD podem usar a CLI do Azure ou a CLI do Desenvolvedor do Azure para provisionar a infraestrutura pré-configurada e controlada sem nem mesmo ter acesso à assinatura subjacente ou às identidades necessárias para fazer isso. Quer você use algo como ADE ou não, seu sistema de entrega contínua preferido pode ajudá-lo a atualizar a infraestrutura com segurança, separando segredos e fornecendo conteúdo de IaC de locais que os desenvolvedores não podem acessar ou modificar por conta própria.

Habilite o autoatendimento em cenários além da entrega contínua do aplicativo

Embora os conceitos de CI e CD estejam vinculados ao desenvolvimento de aplicativos, muitas das coisas que seus clientes internos desejam provisionar não estão diretamente vinculadas a um aplicativo específico. Isso pode ser infraestrutura compartilhada, criação de um repositório, ferramentas de provisionamento e muito mais.

Para entender onde isso pode ajudar, pense em onde você tem atualmente processos manuais ou baseados em central de serviços. Para cada um, pense nestas perguntas:

Com que frequência esse processo acontece?
O processo é lento, propenso a erros ou requer um trabalho significativo para ser alcançado?
Esses processos são manuais devido a uma etapa de aprovação necessária ou simplesmente falta de automação?
Os aprovadores estão familiarizados com os sistemas de controle do código-fonte e os processos de solicitação de pull?
Quais são os requisitos de auditoria para os processos? Eles diferem dos requisitos de auditoria do seu sistema de controle de origem?
Existem processos com os quais você pode começar com menor risco antes de passar para os mais complexos?

Identifique processos frequentes, de alto esforço ou propensos a erros como alvos potenciais para automatizar primeiro.

Use o padrão tudo como código

Uma das coisas boas sobre o git, além de sua onipresença, é que ele se destina a ser uma fonte de informações segura e auditável. Além do histórico de confirmação e dos controles de acesso, conceitos como solicitações de pull e proteção de branch fornecem uma maneira de estabelecer revisores específicos, um histórico de conversas e/ou verificações automatizadas que devem passar antes de serem mescladas no branch principal. Quando combinado com mecanismos de tarefas flexíveis, como os encontrados em sistemas de CI/CD, você tem uma estrutura de automação segura.

A ideia por trás de tudo como código é que você pode transformar quase tudo em um arquivo em um repositório git seguro. Diferentes ferramentas ou agentes conectados ao repositório podem ler o conteúdo. Tratar tudo como código ajuda na repetibilidade por meio de modelos e simplifica o autoatendimento do desenvolvedor. Vamos ver vários exemplos de como isso pode funcionar.

Aplique padrões de IaC a qualquer infraestrutura

Embora a IaC tenha ganhado popularidade por ajudar a automatizar a entrega de aplicativos, o padrão se estende a qualquer infraestrutura, ferramentas ou serviços que você queira provisionar e configurar, não apenas aqueles vinculados a um aplicativo específico. Por exemplo, K8s compartilhados com clusters com o Flux instalado, provisionando algo como o DataDog que é usado por várias equipes e aplicativos ou até mesmo configurando suas ferramentas de colaboração favoritas.

A maneira como isso funciona é que você tem um repositório centralizado separado e seguro que abriga uma série de arquivos que representam o que deve ser provisionado e configurado (neste caso, qualquer coisa, desde Bicep, Terraform até gráficos do Helm e outros formatos nativos do Kubernetes). Uma equipe de operações ou outro conjunto de administradores possui o repositório e os desenvolvedores (ou sistemas) podem enviar solicitações de pull. Depois que essas PRs são mescladas na ramificação principal por esses administradores, as mesmas ferramentas de CI/CD usadas durante o desenvolvimento do aplicativo podem entrar em ação para processar as alterações. Considere esta ilustração que usa GitHub Actions e IaC e identidades de implantação hospedadas em Ambientes de Implantação do Azure:

Se você já estiver usando uma abordagem GitOps para implantação de aplicativos, também poderá reutilizar essas ferramentas. A combinação de ferramentas como o Flux e o Azure Service Operator permite que você expanda para fora do Kubernetes:

Em ambos os casos, você tem uma fonte de informações totalmente gerenciada, reproduzível e auditável – mesmo que o que é produzido não seja para um aplicativo. Assim como no desenvolvimento de aplicativos, todos os segredos ou identidades gerenciadas necessários são armazenados no mecanismo de pipeline/fluxo de trabalho ou nos recursos nativos de um serviço de provisionamento.

Como as pessoas que fazem as PRs não terão acesso direto a esses segredos, ele fornece uma maneira para os desenvolvedores iniciarem com segurança ações que eles não têm permissão direta para fazer sozinhos. Isso permite que você siga o princípio do menor privilégio e, ao mesmo tempo, ofereça aos desenvolvedores uma opção de autoatendimento.

Acompanhe a infraestrutura provisionada

Ao começar a dimensionar essa abordagem, pense em como deseja rastrear a infraestrutura que foi provisionada. Seu repositório git é uma fonte de verdade para a configuração, mas não fornece os URIs específicos e as informações de estado sobre o que você criou. No entanto, seguir uma abordagem de tudo como código fornece uma fonte de informações a ser explorada para sintetizar um inventário da infraestrutura provisionada. Seu provisionador também pode ser uma boa fonte dessas informações que você pode acessar. Por exemplo, os Ambientes de Implantação do Azure incluem recursos de acompanhamento de ambiente dos quais os desenvolvedores têm visibilidade.

Para saber mais sobre o acompanhamento em várias fontes de dados, consulte Criar uma base de autoatendimento para desenvolvedores.

Aplicar a segurança como código e a política como padrões de código

Embora o provisionamento da infraestrutura seja útil, é igualmente importante garantir que esses ambientes sejam seguros e geralmente sigam as políticas da sua organização. Isso levou ao surgimento do conceito de "política como código". Aqui, os arquivos de configuração em um repositório de controle do código-fonte podem ser usados para fazer coisas como verificar a segurança da unidade ou aplicar políticas de infraestrutura.

Muitos produtos e projetos de software livre diferentes adotaram o suporte a essa abordagem, incluindo Azure Policy, Open Policy Agent, GitHub Advanced Security e GitHub CODEOWNERS, entre outros. Ao selecionar sua infraestrutura, serviços ou ferramentas de aplicativos, certifique-se de avaliar o quão bem eles suportam esses padrões. Para obter mais informações sobre como refinar seu aplicativo e governança, consulte Refinar sua plataforma de aplicativo.

Use tudo como código para seus próprios cenários

Tudo como código estende esses padrões a uma ampla variedade de tarefas de automação e configuração além da IaC. Ele pode suportar não apenas a criação ou configuração de qualquer tipo de infraestrutura, mas também a atualização de dados ou o acionamento de fluxos de trabalho em qualquer sistema downstream.

A PR se torna uma boa experiência de usuário de autoatendimento de linha de base para vários processos diferentes, especialmente quando você está começando. Os processos naturalmente ganham os benefícios de segurança, auditabilidade e reversão que o próprio git oferece e os sistemas envolvidos também podem mudar com o tempo sem afetar a experiência do usuário.

Equipes como código

Um exemplo de aplicação de tudo como código aos seus próprios cenários é o padrão de equipes como código. As organizações aplicam esse padrão para padronizar a associação à equipe e, em alguns casos, os direitos de ferramentas/serviços do desenvolvedor em uma ampla variedade de sistemas. Esse padrão elimina os processos manuais de integração e desligamento da central de serviços que são impulsionados pela necessidade de desenvolvedores e operadores de sistemas acessarem seus próprios conceitos de agrupamento, usuário e acesso. Os processos manuais das centrais de serviços são um risco potencial de segurança porque é possível provisionar o acesso em excesso. Ao usar as equipes como padrão de código, a combinação de solicitações git e pull pode habilitar o autoatendimento de uma fonte de dados auditável.

Para obter um exemplo de uma variação madura e extensa desse padrão, confira a postagem no blog do GitHub sobre como eles gerenciam os direitos. O GitHub também abriu o código de sua sofisticada implementação de direitos para você experimentar ou adotar. Embora a postagem no blog descreva todos os direitos dos funcionários, você pode aplicar o conceito de equipes como código a cenários de equipe de desenvolvimento com escopo mais restrito. Essas equipes de desenvolvimento podem não estar representadas em um organograma de funcionários e envolvem ferramentas ou serviços proprietários que podem complicar a integração ou desligamento dos membros da equipe.

Aqui está um resumo de uma variação simplificada dessa ideia que usa um sistema de CI/CD e grupos de provedores de identidade para coordenar atualizações:

Neste exemplo:

Cada sistema envolvido foi configurado para usar seu provedor de identidade (por exemplo, ID do Microsoft Entra) para SSO (logon único).
Você usará grupos de provedores de identidade (por exemplo, grupos do Entra) em sistemas para gerenciar a associação por função para reduzir a complexidade e manter a auditoria centralizada.

Em um alto nível, veja como esse padrão funciona:

Um repositório git central e bloqueado tem um conjunto de arquivos (normalmente YAML) que representam cada equipe abstrata, associação de usuário relacionada e funções de usuário. Proprietários ou aprovadores para alterações de equipe também podem ser armazenados nesse mesmo local (por exemplo, por meio de CODEOWNERS). A referência a um usuário nesses arquivos é o provedor de identidade, mas esse repositório atua como a fonte da verdade para essas equipes (mas não para os usuários).
Todas as atualizações desses arquivos são feitas por meio de solicitações de pull. Isso vincula conversas e participantes relacionados à solicitação de git commit para auditabilidade.
Leads e usuários individuais podem fazer PRs para adicionar/remover pessoas, e líderes de desenvolvimento e outras funções podem criar novas equipes usando PRs com um novo arquivo de equipe de um modelo.
Sempre que uma PR é mesclada em main, um sistema de CI/CD vinculado ao repositório atualiza o sistema do provedor de identidade e todos os sistemas downstream, conforme apropriado.

Especificamente, o sistema CI/CD:

Usa a API do sistema do provedor de identidade apropriada para criar ou atualizar um grupo de provedores de identidade por função com exatamente os indivíduos no arquivo (nem mais, nem menos).
Usa APIs para cada sistema downstream para vincular esse conceito de agrupamento de sistemas a um grupo de provedores de identificação para cada função (exemplo: GitHub e Azure DevOps). Isso pode resultar em um relacionamento um-para-muitos entre sua equipe e o sistema downstream para representar uma função.
(Opcionalmente) Usa APIs para cada sistema downstream para implementar a lógica de permissões vinculada ao mecanismo de agrupamento do sistema.
Usa uma API para atualizar um armazenamento de dados bloqueado com os resultados (incluindo a associação das IDs da equipe do sistema downstream) que podem ser consumidos para qualquer um dos seus sistemas criados internamente. Você também pode armazenar associações para diferentes representações do sistema de IDs de usuário para o mesmo usuário/conta do provedor de identidade aqui, se necessário.

Se sua organização já estiver usando algo como o Entra Entitlement Management, você poderá omitir o gerenciamento da associação de grupo desse padrão.

Suas necessidades e políticas podem mudar as especificidades, mas o padrão geral pode ser adaptado a qualquer número de variações. Todos os segredos necessários para integração com qualquer sistema downstream são mantidos no sistema de CI/CD (por exemplo, no GitHub Actions, Azure Pipelines) ou em algo como o Azure Key Vault.

Usar fluxos de trabalho parametrizados acionados manualmente ou externamente

Alguns dos problemas relacionados ao autoatendimento que você identifica podem não ser propícios ao uso de arquivos no Git. Ou você pode ter uma interface do usuário que deseja usar para impulsionar a experiência de autoatendimento.

Felizmente, a maioria dos sistemas de CI, incluindo GitHub Actions e Azure Pipelines, tem a capacidade de configurar um fluxo de trabalho com entradas que você pode disparar manualmente por meio de suas interfaces de usuário ou CLIs. Considerando que os desenvolvedores e as funções de operações relacionadas provavelmente já estão familiarizados com essas experiências do usuário, os gatilhos manuais podem aumentar o padrão de tudo como código para habilitar a automação de atividades (ou trabalhos) que não têm uma representação natural de arquivo ou devem ser totalmente automatizadas sem exigir um processo de PR.

Seu sistema de CI pode permitir que você opte por acionar esses fluxos de trabalho ou pipelines de suas próprias experiências de usuário por meio de uma API. Para GitHub Actions, a chave para fazer isso funcionar é a API REST do Actions para disparar um evento de expedição de fluxo de trabalho para disparar uma execução de fluxo de trabalho. Os gatilhos do Azure DevOps são semelhantes e você também pode usar a API do Pipeline do Azure DevOps para execuções. Você provavelmente verá os mesmos recursos em outros produtos. Seja disparado manualmente ou por meio de uma API, cada fluxo de trabalho pode dar suporte a um conjunto de entradas adicionando uma configuração workflow_dispatch ao arquivo YAML do fluxo de trabalho. Por exemplo, é assim que os kits de ferramentas do portal, como o Backstage.io , interagem com o GitHub Actions.

O fluxo de trabalho ou o sistema de trabalho do seu sistema de CI/CD, sem dúvida, rastreia atividades, relata o status anterior e tem logs detalhados que os desenvolvedores e as equipes de operações podem usar para ver o que deu errado. Dessa forma, ele tem algumas das mesmas vantagens de segurança, auditabilidade e visibilidade que o padrão tudo como código. No entanto, uma coisa a ter em mente é que todas as ações executadas por esses fluxos de trabalho ou pipelines se parecem com uma identidade do sistema (por exemplo, entidade de serviço ou identidade gerenciada na ID do Microsoft Entra) para sistemas downstream.

Você terá visibilidade de quem inicia solicitações em seu sistema de CI/CD, mas deve avaliar se essas informações são suficientes e garantir que suas configurações de retenção de CI/CD estejam em conformidade com seus requisitos de auditoria para casos em que essas informações são críticas.

Em outros casos, as ferramentas com as quais você se integra podem ter seus próprios mecanismos de rastreamento nos quais você pode confiar. Por exemplo, essas ferramentas de CI/CD quase sempre têm vários mecanismos de notificação disponíveis, como usar um canal do Microsoft Teams ou Slack , que pode permitir que você mantenha qualquer pessoa enviando uma solicitação para obter atualizações de status e o canal fornece um registro informal do que aconteceu. Esses mesmos mecanismos de fluxos de trabalho geralmente já são projetados para se integrar a ferramentas de operações para estender ainda mais a utilidade desses padrões.

Em resumo, você pode implementar alguma automação usando arquivos armazenados em um repositório de controle do código-fonte, graças à flexibilidade das ferramentas de CI/CD e suas experiências de usuário prontas para uso. Para ver como as plataformas internas de desenvolvedor podem usar essa abordagem como ponto de partida sem comprometer os recursos mais sofisticados ao longo do tempo, consulte Criar uma base de autoatendimento para desenvolvedores.

Automatize a configuração de ambientes de codificação de desenvolvedores

Outro problema comum em sistemas de engenharia é a inicialização e normalização do ambiente de codificação do desenvolvedor. Aqui estão alguns dos problemas comuns que você pode ouvir falar nesta área:

Em alguns casos, pode levar semanas para que um desenvolvedor chegue à primeira solicitação de pull. Essa é uma área problemática quando você transfere desenvolvedores entre equipes de recursos e projetos com bastante frequência (por exemplo, em organizações matriciais), precisa aumentar os contratados ou está em uma equipe que está em fase de contratação.
A inconsistência entre os desenvolvedores e com seus sistemas de CI pode levar a problemas frequentes de "funciona na minha máquina", mesmo para membros experientes da equipe.
A experimentação e a atualização de estruturas, tempos de execução e outros softwares também podem quebrar os ambientes de desenvolvedor existentes e levar à perda de tempo tentando descobrir exatamente o que deu errado.
Para líderes de desenvolvimento, as revisões de código podem retardar o desenvolvimento, pois podem exigir uma alteração de configuração para testá-las e desfazê-las assim que a revisão for concluída.
Os membros da equipe e os operadores também precisam gastar tempo aumentando as funções relacionadas além do desenvolvimento (operadores, controle de qualidade, negócios, patrocinadores) para ajudar a testar, ver o progresso, treinar funções de negócios e evangelizar o trabalho que a equipe está fazendo.

Parte de seus caminhos pavimentados

Para ajudar a resolver esses problemas, pense na configuração de ferramentas e utilitários específicos como parte de seus caminhos pavimentados bem definidos. A configuração do computador do desenvolvedor de scripts pode ajudar e você pode reutilizar esses mesmos scripts em seu ambiente de CI. No entanto, considere oferecer suporte a ambientes de desenvolvimento em contêineres ou virtualizados devido aos benefícios que eles podem oferecer. Esses ambientes de codificação podem ser configurados com antecedência de acordo com as especificações da sua organização ou projeto.

Substituição de estação de trabalho e direcionamento do Windows

Se você estiver direcionando o Windows ou quiser fazer a virtualização completa da estação de trabalho (ferramentas de cliente e configurações do sistema operacional host, além de configurações específicas do projeto), as VMs geralmente fornecem a melhor funcionalidade. Esses ambientes podem ser úteis para qualquer coisa, desde o desenvolvimento de cliente Windows até o serviço Windows ou o gerenciamento e manutenção de aplicativos Web de estrutura completa do .NET.

Abordagem	Exemplos
Usar VMs hospedadas na nuvem	O Microsoft Dev Box é uma opção completa de virtualização de estação de trabalho do Windows com integração interna ao software de gerenciamento de desktop.
Usar VMs locais	O Hashicorp Vagrant é uma boa opção e você pode usar o HashiCorp Packer para criar imagens de VM para ele e para o Dev Box.

Virtualização do espaço de trabalho e direcionamento do Linux

Se você estiver direcionando o Linux, considere uma opção de virtualização de espaço de trabalho. Essas opções se concentram menos na substituição da área de trabalho do desenvolvedor e mais em espaços de trabalho específicos do projeto ou do aplicativo.

Abordagem	Exemplos
Usar contêineres hospedados na nuvem	O GitHub Codespaces é um ambiente baseado em nuvem para Dev Containers que dá suporte à integração com o VS Code, o IntelliJ da JetBrains e ferramentas baseadas em terminal. Se esse serviço ou um serviço semelhante não atender às suas necessidades, você poderá usar o suporte a túneis remotos ou SSH do VS Code com contêineres de desenvolvimento em VMs remotas do Linux. A opção baseada em túnel que não funciona apenas com o cliente, mas também com o vscode.dev baseado na Web.
Usar contêineres locais	Se você preferir uma opção de Contêineres de Desenvolvimento local em vez disso ou além de uma hospedada na nuvem, os Contêineres de Desenvolvimento têm suporte sólido no VS Code, suporte no IntelliJ e outras ferramentas e serviços.
Usar VMs hospedadas na nuvem	Se você achar que os contêineres são muito limitantes, o suporte a SSH em ferramentas como o VS Code ou ferramentas do JetBrains, como o IntelliJ, permite que você se conecte diretamente às VMs do Linux que você mesmo gerencia. O VS Code tem a opção baseada em túnel que também funciona aqui.
Usar o subsistema do Windows para Linux	Se seus desenvolvedores estiverem exclusivamente no Windows, o Windows Subsystem for Linux (WSL) é uma ótima maneira de os desenvolvedores direcionarem o Linux localmente. Você pode exportar uma distribuição WSL para sua equipe e compartilhá-la com tudo configurado. Para uma opção de nuvem, os serviços de estação de trabalho em nuvem, como o Microsoft Dev Box, também podem aproveitar o WSL para direcionar o desenvolvimento do Linux.

Crie modelos de aplicativos de início correto que incluem a configuração de permanência correta

A grande vantagem do padrão "tudo como código" é que ele pode manter os desenvolvedores nos caminhos pavimentados que você estabeleceu desde o início. Se isso for um desafio para sua organização, os modelos de aplicativo podem rapidamente se tornar uma maneira crítica de reutilizar blocos de construção para impulsionar a consistência, promover a padronização e codificar as práticas recomendadas da sua organização.

Para começar, você pode usar algo tão simples quanto um repositório de modelos do GitHub, mas se sua organização seguir um padrão monorepo , isso poderá ser menos eficaz. Você também pode criar modelos que ajudem a configurar algo que não esteja diretamente relacionado a uma árvore de origem do aplicativo. Em vez disso, você pode usar um mecanismo de modelagem como cookiecutter, Yeoman ou algo como a CLI do Desenvolvedor do Azure (azd) que, além de modelos e configuração simplificada de CI/CD, também fornece um conjunto conveniente de comandos de desenvolvedor. Como a CLI do Desenvolvedor do Azure pode ser usada para conduzir a configuração do ambiente em todos os cenários, ela se integra aos Ambientes de Implantação do Azure para fornecer segurança aprimorada, IaC integrada, acompanhamento do ambiente, separação de preocupações e configuração simplificada do CD.

Depois de ter um conjunto de modelos, os líderes de desenvolvimento podem usar essas ferramentas de linha de comando ou outras experiências de usuário integradas para estruturar seu conteúdo para seus aplicativos. No entanto, como os desenvolvedores podem não ter permissão para criar repositórios ou outro conteúdo de seus modelos, essa também é outra oportunidade de usar fluxos de trabalho/pipelines parametrizados e acionados manualmente. Você pode configurar entradas para que seu sistema de CI/CD crie qualquer coisa, desde um repositório até a infraestrutura em seu nome.

Ficar certo e acertar

No entanto, para ajudar a dimensionar, esses modelos de aplicativo devem fazer referência a blocos de construção centralizados sempre que possível (por exemplo, modelos de IaC ou até mesmo fluxos de trabalho/pipelines de CI/CD). Na verdade, tratar esses blocos de construção centralizados como sua própria forma de modelos de começar certo pode ser uma estratégia eficaz para resolver alguns dos problemas que você identificou.

Cada um desses modelos individuais pode ser aplicado não apenas a novos aplicativos, mas também aos existentes que você pretende atualizar como parte de uma campanha de acerto para lançar diretrizes atualizadas ou aprimoradas. Melhor ainda, essa centralização ajuda a manter os aplicativos novos e existentes corretos, permitindo que você evolua ou expanda suas práticas recomendadas ao longo do tempo.

Conteúdo do modelo

Recomendamos considerar as seguintes áreas ao criar modelos.

Área	Detalhes
Código-fonte de exemplo suficiente para orientar padrões de aplicativos, SDKs e uso de ferramentas	Inclua código e configuração para orientar os desenvolvedores em relação a linguagens, modelos e serviços de aplicativos, APIs, SDKs e padrões de arquitetura recomendados. Certifique-se de incluir código para rastreamento distribuído, registro em log e observabilidade usando as ferramentas de sua escolha.
Scripts de compilação e implantação	Forneça aos desenvolvedores uma maneira comum de disparar uma compilação e uma implantação local/sandbox. Inclua a configuração de depuração no IDE/editor para as ferramentas de sua escolha para usá-las. Essa é uma maneira importante de evitar dores de cabeça de manutenção e evitar que o CI/CD fique fora de sincronia. Se o mecanismo de modelagem for opinativo como a CLI do Desenvolvedor do Azure, talvez já haja comandos que você possa usar.
Configuração para CI/CD	Forneça fluxos de trabalho/pipelines para criar e implantar aplicativos com base em suas recomendações. Aproveite os fluxos de trabalho/pipelines centralizados, reutilizáveis ou modelados para ajudar a mantê-los atualizados. Na verdade, esses fluxos de trabalho/pipelines reutilizáveis podem ser modelos próprios de início. Certifique-se de considerar uma opção para disparar manualmente esses fluxos de trabalho.
Infraestrutura como ativos de código	Forneça configurações de IaC recomendadas, incluindo referências a módulos gerenciados centralmente ou itens de catálogo, para garantir que qualquer configuração de infraestrutura siga as práticas recomendadas desde o início. Essas referências também podem ajudar as equipes a se manterem corretas com o passar do tempo. Combinado com fluxos de trabalho/pipelines, você também pode incluir IaC ou EaC para provisionar praticamente qualquer coisa.
Segurança e política como ativos de código	O movimento DevSecOps moveu a configuração de segurança para o código, o que é ótimo para modelos. Algumas políticas como artefatos de código também podem ser aplicadas no nível do aplicativo. Inclua tudo, desde arquivos como CODEOWNERS até configurações de verificação como dependabot.yaml no GitHub Advanced Security. Forneça fluxos de trabalho/execuções de pipeline agendados para verificações usando algo como o Defender para Nuvem junto com execuções de teste de ambiente. Isso é importante para a segurança da cadeia de suprimentos e certifique-se de levar em consideração as imagens de contêiner, além dos pacotes e códigos de aplicativos. Essas etapas ajudam as equipes de desenvolvimento a permanecerem certas.
Observabilidade, monitoramento e registro em log	Parte da habilitação do autoatendimento é fornecer visibilidade fácil dos aplicativos depois de implantados. Além da infraestrutura de tempo de execução, certifique-se de incluir a configuração para observabilidade e monitoramento. Na maioria dos casos, há um aspecto de IaC a ser configurado (por exemplo, implantação de agente, instrumentação), enquanto em outros pode ser outro tipo de artefato de código de configuração como (por exemplo, painéis de monitoramento do Azure Application Insights). Por fim, certifique-se de incluir código de exemplo para rastreamento distribuído, registro em log e observabilidade usando as ferramentas de sua escolha.
Configuração do ambiente de codificação	Inclua arquivos de configuração para codificação de linters, formatadores, editores e IDEs. Inclua scripts de instalação junto com arquivos de virtualização de espaço de trabalho ou estação de trabalho, como devcontainer.json, devbox.yaml, Dockerfiles focados no desenvolvedor, arquivos Docker Compose ou Vagrantfiles.
Configuração de teste	Forneça arquivos de configuração para testes de unidade e mais aprofundados usando seus serviços preferidos, como o Microsoft Playwright Testing for UI ou o Azure Load Testing.
Configuração da ferramenta de colaboração	Se o seu sistema de gerenciamento de problemas e gerenciamento de controle do código-fonte oferecer suporte a modelos de tarefa/problema/PR como código, inclua-os também. Nos casos em que mais configuração é necessária, você pode opcionalmente fornecer um fluxo de trabalho/pipeline que atualiza seus sistemas usando uma CLI ou API disponível. Isso também pode permitir que você configure outras ferramentas de colaboração, como Microsoft Teams ou Slack.