Aplicar sistemas de engenharia de software

Depois de entender os problemas que você deseja resolver primeiro em sua jornada de engenharia de plataforma, melhorar o autoatendimento do desenvolvedor pode chegar ao topo da lista. 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ó serão familiares para você e seus clientes internos, mas também podem habilitar uma ampla variedade de cenários de automação, mesmo que a experiência inicial do usuário não seja bonita.

Este artigo fornecerá algumas dicas para aplicar seus sistemas de engenharia para lidar com uma matriz mais ampla de cenários de autoatendimento e como você pode encapsular as melhores práticas em modelos que ajudam você a começar corretamente e a se manter correto.

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

Os sistemas de engenharia são um aspecto crítico da sua plataforma de desenvolvedor interno. No entanto, se você ainda não tiver sistemas direcionados a pelo menos alguns dos locatários main de DevOps e DevSecOps, os problemas que você identificar provavelmente informarão você para começar por lá. As plataformas de desenvolvedor internas se acumulam a partir delas para reduzir a carga cognitiva para todos os envolvidos.

Para recapitular, o DevOps combina desenvolvimento e operações para unir pessoas, processos e tecnologia no planejamento, desenvolvimento, entrega e operações de aplicativos. Ele destina-se a melhorar a colaboração entre funções historicamente em silos, 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. DevSecOps camadas nesse loop com práticas de segurança contínuas em todo o processo de desenvolvimento de aplicativos.

O centro de recursos de DevOps da Microsoft é um ótimo lugar para procurar conselhos sobre os tipos de processos e sistemas necessários, portanto, não abordaremos esses detalhes nesta seção. Estes se tornam ingredientes essenciais à medida que você avança. E não se esqueça de considerar os tópicos recentes do DevSecOps, como a segurança da cadeia de fornecedores de contêineres , em seus planos.

Para obter mais informações sobre comentários contínuos, consulte métricas a serem consideradas. Você também pode saber mais sobre as ferramentas para uso nas áreas de observabilidade, monitoramento e comentários contínuos em Refinar sua plataforma de aplicativo.

No restante deste artigo, nos concentraremos em melhorias mais diretamente atribuídas à movimentação 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.

Estabelecer seus caminhos pavimentados desejados

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

À medida que você começa a mudar para uma mentalidade de produto, você pode pensar nos sistemas de engenharia dentro desses caminhos pavimentados como consistindo em ferramentas gerenciadas centralmente como um serviço para as equipes de desenvolvimento. Equipes individuais ou divisões dentro de sua organização podem então se desviar, mas espera-se que gerenciem, mantenham e paguem por suas ferramentas separadamente enquanto ainda estão aderindo 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 uma 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 em uma 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 De Varejo Multinacional Europeia

Considerando que uma meta fundamental para a engenharia de plataforma é mudar para a mentalidade do produto em que você fornece valor para 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 entradas e resolvam 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 desejem mudar para um caminho com suporte ao longo do tempo.

Se você preferir uma estratégia de consolidação, tenha em mente que migrar aplicativos existentes pode ser mais trabalho do que você espera, 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 roteado considerarão mover-se assim que o novo caminho pavimentado mostrar seu valor para a organização. Nesse ponto, você pode executar uma campanha get right para colocar todos em seu estado desejado através da comunicação bidirecional, já que as equipes de desenvolvimento veem isso como um benefício em vez de 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 comentários sobre como melhorar os caminhos pavimentados.

Independentemente disso, tente evitar exigir o uso de seus caminhos pavimentados. A maneira mais eficaz de implementá-los é enfatizar quais equipes saem delas em vez de através da adoção forçada. Como sua plataforma interna de desenvolvedores se concentra em fazer exatamente essas mesmas equipes felizes, a pressão de orçamento e de tempo para valor sobre líderes individuais tende a cuidar do resto. Faça campanhas certas e, em seguida, forneça um caminho para conversas bidirecionais da melhor maneira para aqueles em um caminho não roteado para mudar.

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

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

Habilitar o provisionamento automático de infraestrutura de aplicativo durante a entrega contínua

Se ainda não estiver implementado, os problemas identificados durante o planejamento provavelmente apontarão para problemas que a CI (integração contínua) e a CD (entrega contínua) podem ajudar a resolve. Produtos como GitHub Actions, Azure DevOps, Jenkins, juntamente com soluções GitOps baseadas em pull, como Flux ou Argo CD, existem nesse 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, também convém considerar 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 em Serviço de Kubernetes do Azure: uma usando implantações baseadas em push e uma implantação baseada em pull (GitOps).

Para saber mais sobre cada abordagem, confira CI/CD para aplicativos AKS com GitHub Actions e Gitflow.

O que você escolhe geralmente é orientado pelo conjunto de habilidades de IaC existente e pelos detalhes da plataforma de aplicativo de destino. A abordagem do 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 a maior flexibilidade, considerando o número de opções disponíveis para ele. Esperamos que a maioria das organizações use uma combinação das duas. Independentemente disso, tornar-se bem versado em práticas de IaC ajudará você a aprender padrões que se aplicam a cenários de automação adicionais.

Centralizar 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 Radius ou Gráficosdo Helm armazenados em um registro de artefato OCI nativo de nuvem, como Registro de Contêiner do Azure (ACR),DockerHub ou o catálogo em Ambientes de Implantação do Azure (ADE). 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 personalizadas como o Operador de Serviço do Azure podem dar suporte adicional para outros tipos de recursos do Azure, outras ferramentas, como recursos de suporte do Crossplane em várias nuvens. Eles permitem que você use gráficos centralizados ou comuns do Helm em algo como o ACR para uma matriz 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 beneficiar 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 que você usa. Por exemplo , os Aplicativos de Contêiner do Azure (ACA) e o recente projeto experimental de incubação de OSS radius são mais opinativos do que usar o Kubernetes diretamente, mas também simplificar 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 IaC centralizada e gerenciada em vez de ter definições completas em sua árvore de origem tem benefícios significativos.

Persistir quaisquer identidades ou segredos de provisionamento necessários de uma maneira que os desenvolvedores não possam acessá-los diretamente às camadas nos blocos de construção básicos para governança. Por exemplo, considere essa ilustração sobre a separação de função 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. Em seguida, as operações podem adicionar identidades gerenciadas e assinaturas por "tipo de ambiente" e atribuir desenvolvedores e outros usuários que têm permissão para usá-los para provisionamento.

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

Habilitar 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 ligam diretamente 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ê atualmente tem 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 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?
• Se um aprovador for necessário, ele estará familiarizado com sistemas de controle do código-fonte e processos de solicitação de pull?
• Quais são os requisitos de auditoria para os processos? Isso difere dos requisitos de auditoria do sistema de controle do código-fonte?
• Há processos que você pode começar com que são de menor risco antes de passar para os mais complexos?

Identifique processos frequentes, de alto esforço ou propensos a erros como possíveis destinos para automatizar primeiro. Em seguida, abordaremos algumas maneiras simples de fazer isso acontecer.

Usar tudo como padrão de código

Uma das coisas interessantes sobre o git além de sua ubiquidade é que ele se destina a ser uma fonte segura e auditável de informações. Além do histórico de commits 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 verificações automatizadas que devem passar antes de se mesclar no branch main. 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. Ferramentas ou agentes diferentes conectados ao repositório podem ler o conteúdo. Tratar tudo como código ajuda na repetição por meio da modelagem e simplifica o autoatendimento do desenvolvedor. Vamos examinar vários exemplos de como isso pode funcionar.

Aplicar 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 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 protegido que abriga uma série de arquivos que representam o que deve ser provisionado e configurado (nesse 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 no branch main por esses administradores, as mesmas ferramentas de CI/CD usadas durante o desenvolvimento de aplicativos podem iniciar 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 do GitOps para implantação de aplicativos, também poderá reutilizar essas ferramentas. Combinar ferramentas como o Flux e o Operador de Serviço do Azure permite que você expanda 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 acontece com o desenvolvimento de aplicativos, todos os segredos ou identidades gerenciadas de que você precisa podem ser 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, ela fornece uma maneira para os desenvolvedores iniciarem com segurança ações que não têm permissão direta para fazer por conta própria. Isso permite que você adere ao princípio de privilégios mínimos, dando aos desenvolvedores uma opção de autoatendimento.

Acompanhar a infraestrutura provisionada

À medida que você começa a dimensionar essa abordagem, pense em como deseja acompanhar a infraestrutura que foi provisionada. Seu repositório git é uma fonte de verdade para a configuração, mas não informa os URIs específicos e as informações de estado sobre o que você criou. No entanto, seguir uma abordagem tudo como código fornece uma fonte de informações para explorar para sintetizar um inventário de infraestrutura provisionada. Seu provisionador também pode ser uma boa fonte dessas informações que você pode explorar. Por exemplo, os Ambientes de Implantação do Azure incluem recursos de acompanhamento de ambiente nos 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 política como padrões de código

Embora a infraestrutura de provisionamento seja útil, garantir que esses ambientes sejam seguros e geralmente sigam as políticas da sua organização é igualmente importante. Isso levou ao aumento 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 impulsionar a verificação de segurança ou aplicar políticas de infraestrutura.

Muitos produtos e projetos de código aberto diferentes adotaram suporte a essa abordagem, incluindo Azure Policy, Agente de Política Aberta, GitHub Advanced Security e CODEOWNERS do GitHub, entre outros. Ao selecionar sua infraestrutura de aplicativo, serviços ou ferramentas, avalie o quão bem eles dão suporte a esses padrões. Para obter mais informações sobre como refinar seu aplicativo e governança, consulte Refinar sua plataforma de aplicativo.

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

Tudo como código estende esses padrões para uma ampla variedade de tarefas de automação e configuração além da IaC. Ele pode dar suporte não apenas à criação ou configuração de qualquer tipo de infraestrutura, mas também à atualização de dados ou ao disparo 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 obtêm os benefícios de segurança, auditoria e reversão que o próprio Git fornece e os sistemas envolvidos também podem mudar ao longo do tempo sem afetar a experiência do usuário.

Teams como código

Um exemplo de como aplicar tudo como código a seus próprios cenários são as equipes como padrão de código. As organizações aplicam esse padrão para padronizar a associação de equipe e, em alguns casos, ferramentas de desenvolvedor/direitos de serviço em uma ampla variedade de sistemas. Esse padrão elimina a integração manual e a integração de processos de central de serviços que são orientados pela necessidade de desenvolvedores e operadores de sistemas acessarem seus próprios conceitos de agrupamento, usuário e acesso. Processos manuais de mesas de serviço são um risco potencial à segurança porque é possível superprovisionar o acesso. 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, marcar a postagem no blog do GitHub sobre como eles gerenciam direitos. O GitHub também criou uma implementação sofisticada de direitos para você experimentar ou adotar. Embora a postagem no blog descreva todos os direitos de funcionários, você pode aplicar as equipes como conceito de código a cenários de equipe de desenvolvimento com escopo mais restrito. Essas equipes de desenvolvimento podem não ser representadas em um organograma de funcionários e envolver ferramentas ou serviços proprietários que podem complicar a integração ou a integração de membros da equipe.

Aqui está o 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:

Para este exemplo, supomos:

1. Cada sistema envolvido foi configurado para usar seu provedor de identidade (por exemplo, Microsoft Entra ID) para SSO (logon único).
2. Você usará grupos de provedores de identidade (por exemplo, grupos entra) entre 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:

1. 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/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).
2. Assim como em outros casos de código, todas as atualizações desses arquivos são feitas por meio de solicitações de pull. Isso vincula conversas e participantes relacionados na solicitação de confirmação do Git para auditoria.
3. Clientes potenciais e usuários individuais podem fazer PRs para adicionar/remover pessoas, e clientes potenciais de desenvolvimento e outras funções podem criar novas equipes usando PRs que com um novo arquivo de equipe de um modelo.
4. 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 de CI/CD:

5. 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 (não mais, nem menos).
6. 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 uma relação um-para-muitos entre sua equipe e o sistema downstream para representar uma função.
7. Opcionalmente, usa APIs para cada sistema downstream para implementar a lógica de permissões vinculada ao mecanismo de agrupamento do sistema.
8. Usa uma API para atualizar um armazenamento de dados bloqueado com os resultados (incluindo associar as IDs de 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.

Observe que, se sua organização já estiver usando algo como o Gerenciamento de Direitos do Entra, você poderá omitir o gerenciamento de associação de grupo desse padrão.

Suas necessidades e políticas podem alterar 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, em GitHub Actions, Azure Pipelines) ou em algo como o Azure Key Vault.

Usar fluxos de trabalho manuais ou disparados externamente e parametrizados

Alguns dos problemas relacionados ao autoatendimento que você identifica podem não ser propícios ao uso de arquivos no Git. Ou talvez você tenha 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 do 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 de usuário, os gatilhos manuais podem aumentar tudo como padrão de código para habilitar a automação para atividades (ou trabalhos) que não têm uma representação de arquivo natural ou devem ser totalmente automatizados sem a necessidade de um processo de PR.

Na verdade, seu sistema de CI pode permitir que você opte por disparar esses fluxos de trabalho/pipelines de suas próprias experiências de usuário por meio de uma API. Para GitHub Actions, a chave para fazer esse trabalho é a API REST de Ações 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 de 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 de workflow_dispatch ao arquivo YAML do fluxo de trabalho. Por exemplo, é assim que kits de ferramentas do portal, como Backstage.io interagem com GitHub Actions.

Sem dúvida, o fluxo de trabalho/sistema de trabalho do sistema de CI/CD rastreia atividades, relata status e tem logs detalhados que as equipes de desenvolvedores e operações podem usar para ver o que deu errado. Dessa forma, ele tem algumas das mesmas vantagens de segurança, auditoria e visibilidade que o padrão de código. No entanto, uma coisa a ter em mente é que todas as ações executadas por esses fluxos de trabalho/pipelines se parecem com uma identidade do sistema (por exemplo, entidade de serviço ou identidade gerenciada em Microsoft Entra ID) 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ê integra podem ter seus próprios mecanismos de acompanhamento com os quais você pode confiar. Por exemplo, essas ferramentas de CI/CD quase sempre têm vários mecanismos de notificação disponíveis, como o uso de um canal do Microsoft Teams ou do Slack, o que pode permitir que você mantenha qualquer pessoa enviando uma solicitação para obter atualizações status e o canal fornece um registro informal do que aconteceu. Esses mesmos mecanismos de fluxos de trabalho geralmente já foram projetados para integrar-se às ferramentas de operações para estender ainda mais a utilidade desses padrões.

Em resumo, você pode implementar uma 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 de desenvolvedor internas podem usar essa abordagem como ponto de partida sem comprometer recursos mais sofisticados ao longo do tempo, consulte Criar uma base de autoatendimento para desenvolvedores.

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

Outro problema comum com o qual você pode identificar que seus sistemas de engenharia podem ajudar é a inicialização e a 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 um desenvolvedor chegar à 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 de matrizes), precisa aumentar os prestadores de serviço ou está em uma equipe que está em fase de contratação.
• A inconsistência entre desenvolvedores e seus sistemas de CI pode levar a problemas frequentes de "funciona no meu computador", mesmo para membros experientes da equipe.
• Estruturas de experimentação e atualização, tempos de execução e outros softwares também podem interromper ambientes de desenvolvedor existentes e resultar em tempo perdido tentando descobrir exatamente o que deu errado.
• Para clientes potenciais de desenvolvimento, as revisões de código podem retardar o desenvolvimento, pois elas podem exigir uma alteração de configuração para testá-las e desfazê-las depois que a revisão for feita.
• Os membros e operadores da equipe também precisam gastar tempo aumentando as funções relacionadas além do desenvolvimento (operadores, QA, 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 resolve esses problemas, pense na configuração de ferramentas e utilitários específicos como parte de seus caminhos 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 dar suporte a ambientes de desenvolvimento em contêineres ou virtualizados devido aos benefícios que eles podem fornecer. Esses ambientes de codificação podem ser configurados com antecedência para as especificações da sua organização ou do 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 do cliente Windows até o serviço Windows ou o gerenciamento e a manutenção de aplicativos Web do .NET full framework.

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 área de trabalho.
Usar VMs locais	O Hashicorp Vagrant é uma boa opção e você pode usar o HashiCorp Packer para criar imagens de VM para ela e para o Dev Box.

Virtualização de workspace e direcionamento para Linux

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

Abordagem	Exemplos
Usar contêineres hospedados na nuvem	O GitHub Codespaces é um ambiente baseado em nuvem para Contêineres de Desenvolvimento que dá suporte à integração com o VS Code, o IntelliJ do JetBrains e as ferramentas baseadas em terminal. Se esse ou um serviço semelhante não atender às suas necessidades, você poderá usar o SSH do VS Code ou o suporte a túneis remotos com Contêineres de Desenvolvimento em VMs remotas do Linux. A opção baseada em túnel que não só funciona com o cliente, mas 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 na nuvem hospedada, 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ê encontrar contêineres muito limitados, o suporte a SSH em ferramentas como o VS Code ou as ferramentas do JetBrains, como o IntelliJ, permitirá que você se conecte diretamente às VMs do Linux que você mesmo gerencia. O VS Code também tem a opção baseada em túnel .
Usar o Subsistema do Windows para Linux	Se os desenvolvedores estiverem exclusivamente no Windows, Subsistema do Windows para Linux (WSL) será 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, serviços de estação de trabalho de nuvem como o Microsoft Dev Box também podem aproveitar o WSL para direcionar o desenvolvimento do Linux.

Criar modelos de aplicativo iniciais corretos que incluem a configuração permanecer correta

A grande coisa sobre tudo como padrão de código é que ele pode manter os desenvolvedores nos caminhos pavimentados que você estabeleceu desde o início. Se esse for um desafio para sua organização, os modelos de aplicativo podem se tornar rapidamente 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. Talvez você também queira 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 parecido com o Azure Developer CLI (azd) que, além de modelar e simplificar a configuração de CI/CD, também fornece um conjunto conveniente de comandos do desenvolvedor. Como o Azure Developer CLI pode ser usado para impulsionar a configuração do ambiente em todos os cenários, ele se integra aos Ambientes de Implantação do Azure para fornecer segurança aprimorada, IaC integrada, acompanhamento de ambiente, separação de preocupações e configuração simplificada de CD.

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

Mantendo-se certo e acertando

No entanto, para ajudar a dimensionar, esses modelos de aplicativo devem referenciar 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, você pode achar que tratar esses blocos de construção centralizados como sua própria forma de modelos de início correto é uma estratégia eficaz para resolve 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 get right para implementar diretrizes atualizadas ou aprimoradas. Ainda melhor, essa centralização ajuda você 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 áreas a seguir ao criar modelos.

Área	Detalhes
Código-fonte de exemplo suficiente para impulsionar padrões de aplicativo, SDKs e uso de ferramentas	Inclua código e configuração para direcionar os desenvolvedores para idiomas, modelos e serviços de aplicativos recomendados, APIs, SDKs e padrões de arquitetura. Certifique-se de incluir código para rastreamento distribuído, registro em log e observabilidade usando suas ferramentas de escolha.
Scripts de compilação e implantação	Forneça aos desenvolvedores uma maneira comum de disparar um build e uma implantação local/área restrita. Inclua a configuração de depuração no IDE/editor para suas ferramentas de escolha para usá-las. Essa é uma maneira importante de evitar dores de cabeça de manutenção e impedir que a CI/CD esteja fora de sincronia. Se o mecanismo de modelagem for opinativo como o Azure Developer CLI, talvez você já possa usar comandos.
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 modelos para ajudar a mantê-los atualizados. Na verdade, esses fluxos de trabalho/pipelines reutilizáveis podem ser modelos corretos próprios. Considere 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 get-go. 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	A movimentação de DevSecOps também 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 como tudo, desde arquivos como CODEOWNERS até a configuração de verificação como dependabot.yaml em GitHub Advanced Security. Forneça fluxos de trabalho agendados/execuções de pipeline para verificações usando algo como o Defender para Nuvem , juntamente com execuções de teste de ambiente. Isso é particularmente importante para a segurança da cadeia de suprimentos e certifique-se de considerar imagens de contêiner , além de pacotes de aplicativos e código. Essas etapas ajudam as equipes de desenvolvimento a permanecerem corretas.
Observabilidade, monitoramento e registro em log	Parte da habilitação do autoatendimento é fornecer visibilidade fácil em aplicativos uma vez implantados. Além da infraestrutura de runtime, inclua a configuração para observabilidade e monitoramento. Na maioria dos casos, há um aspecto de IaC para configurar (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, monitoramento de painéis para Aplicativo Azure Insights). Por fim, inclua o código de exemplo de código para rastreamento distribuído, registro em log e observabilidade usando suas ferramentas de 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 workspace ou de estação de trabalho, como devcontainer.json, devbox.yaml, Dockerfiles focados no desenvolvedor, arquivos do Docker Compose ou Vagrantfiles.
Configuração de teste	Forneça arquivos de configuração para testes de unidade e mais detalhados usando seus serviços preferenciais, como Microsoft Playwright Testing para interface do usuário ou teste de carga do Azure.
Configuração da ferramenta de colaboração	Se o sistema de gerenciamento de gerenciamento de problemas e controle do código-fonte der 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 o Microsoft Teams ou o Slack.

Refinar sua plataforma de aplicativo