Aplicar sistemas de engenharia de software

Assim que compreender os problemas que pretende resolver primeiro no percurso de engenharia da plataforma, a melhoria da gestão personalizada do programador pode chegar ao topo da lista. Uma das formas mais fáceis de começar a ativar experiências personalizadas automatizadas é reutilizar os seus sistemas de engenharia existentes. Estes sistemas não só serão familiares para si e para os seus clientes internos, como também podem ativar uma vasta gama de cenários de automatização, mesmo que a experiência inicial do utilizador não seja bonita.

Este artigo irá fornecer algumas sugestões para aplicar os seus sistemas de engenharia para abordar uma maior variedade de cenários self-service e como pode encapsular as melhores práticas em modelos que o ajudam a começar bem e a manter-se correto.

Avaliar as práticas base de DevOps e DevSecOps

Os sistemas de engenharia são um aspeto crítico da sua plataforma de programador interna. No entanto, se não tiver nenhum sistema que tenha como alvo, pelo menos, alguns dos principais inquilinos do DevOps e do DevSecOps, é provável que os problemas que identificar lhe digam para começar aí. As plataformas de programadores internos são criadas a partir das mesmas 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 planeamento, desenvolvimento, entrega e operações de aplicações. Destina-se a melhorar a colaboração em funções historicamente siloadas, como desenvolvimento, operações de TI, engenharia de qualidade e segurança. Estabelece um ciclo contínuo entre desenvolvimento, implementação, monitorização, observação e comentários. O DevSecOps coloca camadas neste ciclo com práticas de segurança contínuas em todo o processo de desenvolvimento de aplicações.

O centro de recursos do DevOps da Microsoft é um ótimo local para procurar conselhos sobre os tipos de processos e sistemas de que irá precisar, pelo que não abordaremos estes procedimentos detalhadamente nesta secção. Estes tornam-se ingredientes essenciais à medida que avançamos. E não se esqueça de considerar os tópicos recentes do DevSecOps, como a segurança da cadeia de fornecimento de contentores , nos seus planos.

Para obter mais informações sobre comentários contínuos, veja as métricas a considerar. Também pode saber mais sobre as ferramentas para utilização nas áreas de observabilidade, monitorização e feedback contínuo em Refinar a plataforma de aplicações.

No resto deste artigo, vamos focar-nos em melhoramentos mais diretamente atribuídos ao movimento de engenharia da plataforma: caminhos pavimentados, aprovisionamento automatizado de infraestruturas (além da implementação de aplicações), configuração do ambiente de codificação, juntamente com o aprovisionamento self-service e a configuração de ferramentas, recursos de equipa e serviços que não fazem parte direta do ciclo de desenvolvimento de aplicações.

Estabelecer os caminhos pavimentados pretendidos

Se já tiver vários conjuntos de ferramentas que compõem os seus sistemas de engenharia, uma decisão antecipada que terá de tomar é se quer dar um passo em consolidar os mesmos como parte dos seus esforços iniciais de engenharia de plataformas ou se irá suportar uma constelação de ferramentas diferentes desde o início. Na maioria dos casos, definir um conjunto de caminhos pavimentados nesta constelação de ferramentas é mais eficaz e proporciona um maior nível de flexibilidade.

À medida que começa a mudar para uma mentalidade de produto, pode pensar nos sistemas de engenharia dentro destes caminhos pavimentados como sendo compostos por ferramentas geridas centralmente como um serviço para equipas de desenvolvimento. As equipas ou divisões individuais na sua organização podem então desviar-se, mas espera-se que faça a gestão, manutenção e pagamento das respetivas ferramentas separadamente, ao mesmo tempo que cumprem quaisquer requisitos de conformidade. Isto fornece uma forma de alimentar novas ferramentas para o ecossistema sem interrupções, uma vez que pode avaliar qualquer coisa que se desvie para uma possível inclusão num caminho aberto ao longo do tempo. Como disse um líder de engenharia de plataforma:

Ainda podes fazer a tua própria coisa, mas fá-lo numa direcção que vamos... podes mudar o que quiseres, mas isto torna-se da tua responsabilidade. O proprietário das alterações é o proprietário das facas afiadas. - Mark, líder de engenharia de plataformas, Grande Multinacional Europeia Retail Company

Tendo em conta que um dos principais objetivos para a engenharia de plataformas é mudar para a mentalidade do produto onde fornece valor aos seus clientes internos, esta abordagem de constelação normalmente funciona melhor do que um mandato de cima para baixo. À medida que estabelece e refina os seus caminhos pavimentados, deixar alguma flexibilidade permite que as equipas forneçam entradas e resolvam quaisquer requisitos verdadeiramente exclusivos para uma determinada aplicação sem afetar outras pessoas na organização. Isto leva a um conjunto de caminhos totalmente pavimentados e dourados, enquanto outros só são parcialmente pavimentados. Nos casos em que não existem requisitos exclusivos, as equipas de programadores de trabalho extra assumem naturalmente que querem mudar para um caminho suportado ao longo do tempo.

Se preferir uma estratégia de consolidação, tenha em atenção que a migração de aplicações existentes pode ser mais útil do que o esperado, pelo que, para começar, provavelmente irá querer concentrar-se no aspeto de início correto deste espaço e concentrar-se em novos projetos. Isto dá-lhe o seu primeiro caminho pavimentado, enquanto tudo o que existe é inerentemente não repadado. As equipas de desenvolvimento no caminho não remisso considerarão mover-se assim que o seu novo caminho aberto mostrar o respetivo valor para a organização. Nessa altura, pode executar uma campanha get right para fazer com que todos no seu estado pretendido através de comunicações bidirecionais, uma vez que as equipas de programador vêem isto como um benefício em vez de um imposto. Durante a campanha, as equipas de engenharia de plataformas podem concentrar-se em ajudar as equipas a migrar, enquanto as equipas de programadores fornecem feedback sobre como melhorar os caminhos pavimentados.

Seja como for, tente evitar a utilização dos seus caminhos pavimentados. A forma mais eficaz de os lançar é enfatizar o que as equipas obtêm deles e não através da adoção forçada. Uma vez que a sua plataforma interna de programadores se concentra em tornar estas mesmas equipas felizes, a pressão do orçamento e do tempo a valor sobre os líderes individuais tende a tratar do resto. Obtenha as campanhas certas e, em seguida, forneça uma via para conversações bidirecionais da melhor forma para aqueles que estão num caminho não remisso mudar.

Utilizar ferramentas de automatização de programadores para melhorar o self-service para os caminhos abertos

Parte da criação do seu primeiro caminho pavimentado deve ser estabelecer os seus principais produtos de automatização de programadores. Estes são importantes à medida que começa a pensar em ativar as capacidades self-service do programador.

Ativar o aprovisionamento automático da infraestrutura de aplicações durante a entrega contínua

Se ainda não estiver implementado, os problemas que identificou durante o planeamento irão provavelmente apontar 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 o Flux ou o Argo CD, existem neste espaço. Pode começar a utilizar estes tópicos no centro de recursos do Microsoft DevOps.

Mesmo que já tenha implementado uma forma de implementar continuamente a sua aplicação na infraestrutura existente, também deverá considerar a utilização da infraestrutura como código (IaC) para criar ou atualizar a infraestrutura de aplicações necessária como parte do pipeline de CD.

Por exemplo, considere estas ilustrações que mostram duas abordagens que utilizam GitHub Actions para atualizar a infraestrutura e implementar em Azure Kubernetes Service: uma com implementações baseadas em push e uma implementação baseada em pull (GitOps).

Para saber mais sobre cada abordagem, veja CI/CD para aplicações do AKS com GitHub Actions e Gitflow.

O que escolher é, muitas vezes, impulsionado pelo conjunto de competências IaC existente e pelos detalhes da sua plataforma de aplicações de destino. A abordagem do GitOps é mais recente e é popular entre as organizações que utilizam o Kubernetes como base para as suas aplicações, enquanto o modelo baseado em pull dá-lhe atualmente a maior flexibilidade, dado o número de opções disponíveis para o mesmo. Esperamos que a maioria das organizações utilize uma combinação dos dois. Independentemente disso, tornar-se bem versado nas práticas iaC irá ajudá-lo a aprender padrões que se aplicam a cenários de automatização adicionais.

Centralizar IaC num catálogo ou registo para dimensionar e melhorar a segurança

Para gerir e dimensionar o IaC entre aplicações, deve publicar centralmente os artefactos IaC para reutilização. Por exemplo, pode utilizar módulos terraform num registo, módulos bicep, receitas radius ou Gráficos Helm armazenados num registo de Artefactos OCI nativo da cloud, como Azure Container Registry (ACR), DockerHub ou o catálogo em Ambientes de Implementação do Azure (ADE). Para o GitOps e o Kubernetes, a API de Cluster (e implementações como o CAPZ) pode permitir-lhe gerir clusters de cargas de trabalho do Kubernetes, enquanto as definições de recursos personalizadas, 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 clouds. Estes permitem-lhe utilizar gráficos Helm centralizados ou comuns em algo como o ACR para uma maior variedade de cenários.

Centralizar o IaC melhora a segurança ao dar-lhe um melhor controlo sobre quem pode fazer atualizações, uma vez que já não estão armazenadas com o código da aplicação. Existe menos risco de uma quebra acidental causada por uma alteração inadvertida durante uma atualização de código quando especialistas, operações ou engenheiros da plataforma fazem as alterações necessárias. Os programadores também beneficiam destes blocos modulares, uma vez que não têm de criar modelos IaC completos e beneficiar automaticamente das melhores práticas codificadas.

O formato IaC que escolher depende do conjunto de competências existente, do nível de controlo de que precisa e do modelo de aplicação que utiliza. Por exemplo, o Azure Container Apps (ACA) e o recente projeto experimental de incubação radius OSS são mais opinados do que utilizar o Kubernetes diretamente, mas também simplificar a experiência do programador. O módulo de preparação Descrever tipos de serviço cloud pode ajudá-lo a compreender os prós e os contras de diferentes modelos. Independentemente disso, referenciar iaC centralizado e gerido em vez de ter definições completas na árvore de origem tem benefícios significativos.

Manter quaisquer identidades ou segredos de aprovisionamento necessários de uma forma que os programadores não possam aceder diretamente às camadas dos blocos modulares básicos para governação. Por exemplo, considere esta ilustração sobre a separação de funções que pode alcançar com a Azure Deployment Environments (ADE).

Aqui, os engenheiros da plataforma e outros especialistas desenvolvem IaC e outros modelos e colocam-nos num catálogo. Em seguida, as operações podem adicionar identidades geridas e subscrições por "tipo de ambiente" e atribuir programadores e outros utilizadores que tenham permissão para as utilizar para aprovisionamento.

Os programadores ou o pipeline ci/CD podem, em seguida, utilizar a CLI do Azure ou Azure Developer CLI para aprovisionar infraestruturas pré-configuradas e controladas sem sequer terem acesso à subscrição ou identidades subjacentes necessárias para o fazer. Quer utilize ou não algo como a ADE, o seu sistema de entrega contínua de preferência pode ajudá-lo a atualizar a infraestrutura de forma segura e segura ao separar segredos e fornecer conteúdo IaC a partir de localizações às quais os programadores não podem aceder ou modificar por si próprios.

Ativar a gestão personalizada em cenários para além da entrega contínua de aplicações

Embora os conceitos de CI e CD estejam ligados ao desenvolvimento de aplicações, muitas das coisas que os seus clientes internos querem aprovisionar não se ligam diretamente a uma determinada aplicação. Pode ser uma infraestrutura partilhada, criar um repositório, ferramentas de aprovisionamento e muito mais.

Para compreender onde isto pode ajudar, pense onde tem atualmente processos manuais ou baseados no service desk. Para cada um deles, pense nestas perguntas:

• Com que frequência ocorre este processo?
• O processo é lento, propenso a erros ou requer um trabalho significativo para alcançar?
• Estes processos são manuais devido a um passo de aprovação necessário ou simplesmente à falta de automatização?
• Se for necessário um aprovador, está familiarizado com os sistemas de controlo de origem e os processos de pedido Pull?
• Quais são os requisitos de auditoria para os processos? Estas diferenças são diferentes dos requisitos de auditoria do sistema de controlo de origem?
• Existem processos com os quais pode começar que são de menor risco antes de avançar para processos mais complexos?

Identifique processos frequentes, de esforço elevado ou propensos a erros como potenciais destinos para automatizar primeiro. Em seguida, vamos abordar algumas formas simples de fazer isto acontecer.

Utilizar tudo como padrão de código

Uma das coisas boas do git, além da sua ubiquidade, é que se destina a ser uma origem segura e auditável de informações. Para além do histórico de consolidações e dos controlos de acesso, conceitos como pedidos Pull e proteção de ramificações fornecem uma forma de estabelecer revisores específicos, um histórico de conversações e verificações automatizadas que têm de passar antes de se unirem no ramo principal. Quando combinado com motores de tarefa flexíveis como os encontrados em sistemas CI/CD, tem uma arquitetura de automatização segura.

A ideia por trás de tudo como código é que pode transformar quase tudo num ficheiro num repositório git seguro. Diferentes ferramentas ou agentes ligados ao repositório podem ler o conteúdo. Tratar tudo como código ajuda a repetibilidade através de modelos e simplifica a gestão personalizada do programador. Vejamos vários exemplos de como isto pode funcionar.

Aplicar padrões iac a qualquer infraestrutura

Embora a IaC tenha ganho popularidade para ajudar a automatizar a entrega de aplicações, o padrão estende-se a qualquer infraestrutura, ferramentas ou serviços que possa querer aprovisionar e configurar e não apenas aos associados a uma aplicação específica. Por exemplo, k8s partilhados com clusters com o Flux instalado, aprovisionar algo como o DataDog que é utilizado por várias equipas e aplicações ou até mesmo configurar as suas ferramentas de colaboração favoritas.

A forma como isto funciona é que tem um repositório centralizado seguro e separado que aloja uma série de ficheiros que representam o que deve ser aprovisionado e configurado (neste caso, tudo, desde o Bicep, Terraform, até gráficos Helm e outros formatos nativos do Kubernetes). Uma equipa de operações ou outro conjunto de administradores é o proprietário do repositório e os programadores (ou sistemas) podem submeter pedidos Pull. Assim que estes PRs forem intercalados no ramo principal por estes administradores, as mesmas ferramentas de CI/CD utilizadas durante o desenvolvimento de aplicações podem iniciar sessão para processar as alterações. Considere esta ilustração que utiliza GitHub Actions e IaC e identidades de implementação alojadas em Ambientes de Implementação do Azure:

Se já estiver a utilizar uma abordagem do GitOps para a implementação de aplicações, também pode reutilizar estas ferramentas. Combinar ferramentas como o Flux e o Operador de Serviço do Azure permite-lhe expandir-se fora do Kubernetes:

Em ambos os casos, tem uma origem de informação totalmente gerida, reproduzível e auditável, mesmo que o que é produzido não seja para uma aplicação. Tal como acontece com o desenvolvimento de aplicações, todos os segredos ou identidades geridas de que precisa podem ser armazenados no motor de pipeline/fluxo de trabalho ou nas capacidades nativas de um serviço de aprovisionamento.

Uma vez que as pessoas que fazem os PRs não terão acesso direto a estes segredos, fornece uma forma de os programadores iniciarem em segurança ações que não têm permissão direta para realizarem. Isto permite-lhe cumprir o princípio do menor privilégio e, ao mesmo tempo, dar aos programadores uma opção self-service.

Controlar a infraestrutura aprovisionada

À medida que começa a dimensionar esta abordagem, pense em como pretende controlar a infraestrutura que foi aprovisionada. O seu repositório git é uma fonte de verdade para a configuração, mas não indica os URIs específicos e as informações de estado sobre o que criou. No entanto, seguir tudo como uma abordagem de código dá-lhe uma origem de informações para explorar para sintetizar um inventário da infraestrutura aprovisionada. O aprovisionador também pode ser uma boa origem destas informações nas quais pode aceder. Por exemplo, os Ambientes de Implementação do Azure incluem capacidades de controlo de ambientes nas quais os programadores têm visibilidade.

Para saber mais sobre o controlo em várias origens de dados, veja Estruturar uma base self-service para programadores.

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

Embora a infraestrutura de aprovisionamento seja útil, é igualmente importante garantir que estes ambientes são seguros e que, geralmente, seguem as políticas da sua organização. Isto levou ao aumento do conceito de "política como código". Aqui, os ficheiros de configuração num repositório de controlo de origem podem ser utilizados para efetuar ações como a análise de segurança de unidades ou aplicar políticas de infraestrutura.

Muitos produtos e projetos open source diferentes adotaram suporte para esta abordagem, incluindo Azure Policy, Open Policy Agent, GitHub Advanced Security e GitHub CODEOWNERS, entre outros. Ao selecionar a sua infraestrutura de aplicação, serviços ou ferramentas, certifique-se de que avalia como suportam estes padrões. Para obter mais informações sobre como refinar a sua aplicação e governação, veja Refinar a plataforma de aplicações.

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

Tudo como código expande estes padrões para uma grande variedade de tarefas de automatização e configuração para além da IaC. Pode suportar não só a criação ou configuração de qualquer tipo de infraestrutura, mas também a atualização de dados ou acionamento de fluxos de trabalho em qualquer sistema a jusante.

O PR torna-se uma boa experiência de utilizador self-service de linha de base para vários processos diferentes, especialmente quando está a começar. Os processos obtêm naturalmente os benefícios de segurança, auditoria e reversão fornecidos pelo git e os sistemas envolvidos também podem mudar ao longo do tempo sem afetar a experiência do utilizador.

Teams como código

Um exemplo de aplicação de tudo como código nos seus próprios cenários são as equipas como padrão de código. As organizações aplicam este padrão para uniformizar a associação a equipas e, em alguns casos, ferramentas de programador/direitos de serviço em vários sistemas. Este padrão elimina os processos manuais de integração e exclusão do service desk que são impulsionados pela necessidade de os programadores e operadores de sistemas acederem aos seus próprios conceitos de agrupamento, utilizador e acesso. Os processos manuais de service desks são um potencial risco de segurança porque é possível sobreaprovisionar o acesso. Ao utilizar as equipas como padrão de código, a combinação de pedidos Git e Pull pode ativar a gestão personalizada a partir de uma origem de dados auditável.

Para obter um exemplo de uma variação extensa e madura deste padrão, veja a publicação de blogue do GitHub sobre como gerem as Elegibilidades. O GitHub também criou em open source a sua sofisticada implementação de Elegibilidades para experimentar ou adotar. Embora a publicação de blogue descreva todas as elegibilidades dos colaboradores, pode aplicar as equipas como conceito de código a cenários de equipa de desenvolvimento mais restritos. Estas equipas de desenvolvimento podem não estar representadas num organograma de funcionários e envolver ferramentas ou serviços proprietários que podem complicar a integração ou exclusão de membros da equipa.

Eis um resumo de uma variação simplificada desta ideia que utiliza um sistema CI/CD e grupos de fornecedores de identidade para coordenar atualizações:

Para este exemplo, partimos do princípio de que:

1. Cada sistema envolvido foi configurado para utilizar o seu fornecedor de identidade (por exemplo, Microsoft Entra ID) para o início de sessão único (SSO).
2. Irá utilizar grupos de fornecedores de identidade (por exemplo, grupos Entra) entre sistemas para gerir a associação por função para reduzir a complexidade e manter a auditoria centralizada.

A um nível elevado, eis como este padrão funciona:

1. Um repositório git central e bloqueado tem um conjunto de ficheiros (normalmente YAML) que representam cada equipa abstrata, associação de utilizador relacionada e funções de utilizador. Os proprietários/aprovadores de alterações de equipa também podem ser armazenados neste mesmo local (por exemplo, através de CODEOWNERS). A referência a um utilizador nestes ficheiros é o fornecedor de identidade, mas este repositório funciona como a origem da verdade para estas equipas (mas não para os utilizadores).
2. Tal como noutros casos de código, todas as atualizações a estes ficheiros são feitas através de pedidos Pull. Esta ação associa conversações e participantes relacionados no pedido de consolidação do git para fins de auditoria.
3. As oportunidades potenciais e os utilizadores individuais podem criar PRs para adicionar/remover pessoas e as oportunidades potenciais de desenvolvimento e outras funções podem criar novas equipas através de PRs que têm um novo ficheiro de equipa a partir de um modelo.
4. Sempre que um PR é intercalado em principal, um sistema CI/CD associado ao repositório atualiza o sistema do fornecedor de identidade e todos os sistemas a jusante conforme adequado.

Especificamente, o sistema CI/CD:

5. Utiliza a API de sistema do fornecedor de identidade adequada para criar ou atualizar um grupo de fornecedores de identidade por função com exatamente os indivíduos no ficheiro (nem mais, nem menos).
6. Utiliza APIs para cada sistema a jusante para associar esse conceito de agrupamento de sistemas a grupos de fornecedores de identificação para cada função (por exemplo: GitHub e Azure DevOps). Isto pode resultar numa relação um-para-muitos entre a sua equipa e o sistema a jusante para representar uma função.
7. Opcionalmente, utiliza APIs para cada sistema a jusante para implementar a lógica de permissões associada ao mecanismo de agrupamento do sistema.
8. Utiliza uma API para atualizar um arquivo de dados bloqueado com os resultados (incluindo associar os IDs da equipa do sistema a jusante) que podem ser consumidos para qualquer um dos seus sistemas criados internamente. Também pode armazenar associações para diferentes representações de sistema de IDs de utilizador para o mesmo utilizador/conta do fornecedor de identidade aqui, se necessário.

Tenha em atenção que, se a sua organização já estiver a utilizar algo como a Gestão de Direitos de Entra, poderá omitir a gestão da associação a grupos a partir deste padrão.

As suas necessidades e políticas podem alterar as especificações, mas o padrão geral pode ser adaptado a qualquer número de variações. Todos os segredos necessários para integrar em quaisquer sistemas a jusante são mantidos no sistema CI/CD (por exemplo, no GitHub Actions, pipelines do Azure) ou em algo como o Azure Key Vault.

Utilizar fluxos de trabalho parametrizados manuais ou acionados externamente

Alguns dos problemas relacionados com gestão personalizada que identifica podem não ser propícios à utilização de ficheiros no Git. Em alternativa, pode ter uma interface de utilizador que pretende utilizar para impulsionar a experiência self-service.

Felizmente, a maioria dos sistemas de CI, incluindo GitHub Actions e pipelines do Azure, tem a capacidade de configurar um fluxo de trabalho com entradas que pode acionar manualmente através das suas UIs ou CLIs. Dado que os programadores e as funções de operações relacionadas já estão provavelmente familiarizados com estas experiências de utilizador, os acionadores manuais podem aumentar tudo como padrão de código para permitir a automatização para atividades (ou tarefas) que não têm uma representação de ficheiro natural ou devem ser totalmente automatizados sem necessidade de um processo de PR.

Na verdade, o seu sistema CI pode permitir-lhe optar por acionar estes fluxos de trabalho/pipelines a partir das suas próprias experiências de utilizador através de uma API. Por GitHub Actions, a chave para que isto funcione é a API REST de Ações para acionar um evento de distribuição de fluxo de trabalho para acionar uma execução de fluxo de trabalho. Os acionadores do Azure DevOps são semelhantes e também pode utilizar a API de Pipeline do Azure DevOps para execuções. É provável que veja as mesmas capacidades noutros produtos. Quer seja acionado manualmente ou através de uma API, cada fluxo de trabalho pode suportar um conjunto de entradas ao adicionar uma configuração de workflow_dispatch ao ficheiro YAML do fluxo de trabalho. Por exemplo, é assim que os toolkits do portal, como Backstage.io, interagem com GitHub Actions.

O fluxo de trabalho/sistema de trabalho do sistema CI/CD controla, sem dúvida, atividades, reporta o estado das tarefas e tem registos detalhados que tanto os programadores como as equipas de operações podem utilizar para ver o que correu mal. Desta forma, tem algumas das mesmas vantagens de segurança, auditoria e visibilidade que tudo como padrão de código. No entanto, uma coisa a ter em conta é que todas as ações executadas por estes fluxos de trabalho/pipelines se assemelham a uma identidade do sistema (por exemplo, principal de serviço ou identidade gerida no Microsoft Entra ID) para sistemas a jusante.

Terá visibilidade sobre quem inicia pedidos no seu sistema CI/CD, mas deve avaliar se são informações suficientes e certificar-se de que as definições de retenção de CI/CD estão em conformidade com os requisitos de auditoria para casos em que estas informações são críticas.

Noutros casos, as ferramentas que integra podem ter os seus próprios mecanismos de controlo em que pode confiar. Por exemplo, estas ferramentas de CI/CD têm quase sempre vários mecanismos de notificação disponíveis, como utilizar um canal do Microsoft Teams ou slack , o que lhe permite manter qualquer pessoa a submeter um pedido para obter atualizações de estado e o canal fornece um registo informal do que aconteceu. Estes mesmos motores de fluxos de trabalho já foram, muitas vezes, concebidos para integrar com ferramentas de operações para aumentar ainda mais a utilidade destes padrões.

Em resumo, pode implementar uma automatização através de ficheiros armazenados num repositório de controlo de origem graças à flexibilidade das ferramentas ci/CD e às suas experiências de utilizador inativas.

Para ver como as plataformas de programadores internas podem utilizar esta abordagem como um ponto de partida sem comprometer capacidades mais sofisticadas ao longo do tempo, consulte Estruturar uma base self-service para programadores.

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

Outro problema comum que pode identificar que os seus sistemas de engenharia podem ajudar é o arranque e a normalização do ambiente de codificação do programador. Seguem-se alguns dos problemas comuns que poderá ter nesta área:

• Em alguns casos, um programador pode demorar semanas a obter o seu primeiro pedido Pull. Esta é uma área problemática quando transfere programadores entre equipas de funcionalidades e projetos com bastante frequência (por exemplo, em organizações matrizes), precisa de aumentar os empreiteiros ou está numa equipa que está numa fase de contratação.
• A inconsistência entre programadores e com os seus sistemas de CI pode levar a problemas frequentes de "funciona no meu computador", mesmo para membros experientes da equipa.
• A experimentação e atualização de arquiteturas, tempos de execução e outro software também podem interromper ambientes de programador existentes e resultar em tempo perdido ao tentar descobrir exatamente o que correu mal.
• Para as oportunidades potenciais de desenvolvimento, as revisões de código podem abrandar o desenvolvimento, uma vez que podem exigir uma alteração de configuração para testá-las e anulá-las assim que a revisão estiver concluída.
• Os membros e operadores de equipa também têm de gastar tempo a aumentar funções relacionadas para além do desenvolvimento (operadores, QA, negócios, patrocinadores) para ajudar a testar, ver o progresso, formar funções empresariais e evangelizar o trabalho que a equipa está a fazer.

Parte dos seus caminhos pavimentados

Para ajudar a resolver estes problemas, pense na configuração de ferramentas e utilitários específicos como parte dos caminhos abertos bem definidos. A configuração do computador do programador de scripts pode ajudar e pode reutilizar estes mesmos scripts no seu ambiente de CI. No entanto, considere suportar ambientes de desenvolvimento em contentores ou virtualizados devido aos benefícios que podem proporcionar. Estes ambientes de codificação podem ser configurados com antecedência para as especificações da sua organização ou do projeto.

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

Se estiver a filtrar o Windows ou quiser efetuar a virtualização completa da estação de trabalho (ferramentas de cliente e definições do SO anfitrião, além das definições específicas do projeto), as VMs normalmente fornecem a melhor funcionalidade. Estes ambientes podem ser úteis para tudo, desde o desenvolvimento de clientes Windows até ao serviço Windows ou para gerir e manter aplicações Web de arquitetura completa .NET.

Abordagem	Exemplos
Utilizar VMs alojadas na cloud	O Microsoft Dev Box é uma opção completa de virtualização da estação de trabalho do Windows com integração incorporada no software de gestão de ambiente de trabalho.
Utilizar VMs locais	O Hashicorp Vagrant é uma boa opção e pode utilizar a HashiCorp Packer para criar imagens de VMs para o mesmo e para o Dev Box.

Virtualização da área de trabalho e filtragem do Linux

Se estiver a filtrar o Linux, considere uma opção de virtualização de área de trabalho. Estas opções concentram-se menos na substituição do ambiente de trabalho do programador e mais em áreas de trabalho específicas do projeto ou da aplicação.

Abordagem	Exemplos
Utilizar contentores alojados na cloud	O GitHub Codespaces é um ambiente baseado na cloud para Contentores de Programador que suporta a integração com o VS Code, o IntelliJ do JetBrains e as ferramentas baseadas em terminais. Se este ou um serviço semelhante não corresponder às suas necessidades, pode utilizar o SSH do VS Code ou o suporte de túneis remotos com Contentores de Programador em VMs remotas do Linux. A opção baseada em túnel que não só funciona com o cliente, mas também com o vscode.dev baseado na Web.
Utilizar contentores locais	Se preferir uma opção local de Contentores de Programador ou para além de uma opção alojada na cloud, os Contentores de Programador têm suporte sólido no VS Code, suporte no IntelliJ e outras ferramentas e serviços.
Utilizar VMs alojadas na cloud	Se achar que os contentores são demasiado limitadores, o suporte SSH em ferramentas como o VS Code ou as ferramentas JetBrains, como o IntelliJ, permite-lhe ligar diretamente às VMs do Linux que gere. O VS Code também tem uma opção baseada em túnel aqui.
Utilizar o Subsistema Windows para Linux	Se os seus programadores estiverem exclusivamente no Windows, Subsistema Windows para Linux (WSL) é uma excelente forma de os programadores direcionarem o Linux localmente. Pode exportar uma distribuição WSL para a sua equipa e partilhá-la com tudo configurado. Para uma opção na cloud, os serviços de estação de trabalho na cloud, como o Microsoft Dev Box, também podem tirar partido do WSL para direcionar o desenvolvimento do Linux.

Criar modelos de aplicação de início corretos que incluam a configuração de manter-se correta

O melhor de tudo como padrão de código é que pode manter os programadores nos caminhos pavimentados que estabeleceu desde o início. Se este for um desafio para a sua organização, os modelos de aplicação podem rapidamente tornar-se uma forma crítica de reutilizar blocos modulares para impulsionar a consistência, promover a uniformização e codificar as melhores práticas da sua organização.

Para começar, pode utilizar algo tão simples como um repositório de modelos do GitHub, mas se a sua organização seguir um padrão monorepo , poderá ser menos eficaz. Também pode querer criar modelos que ajudem a configurar algo que não esteja diretamente relacionado com uma árvore de origem da aplicação. Em vez disso, pode utilizar um motor de modelo como o cookiecutter, Yeoman ou algo como o Azure Developer CLI (azd) que, além de modelar e simplificar a configuração CI/CD, também fornece um conjunto conveniente de comandos de programador. Uma vez que o Azure Developer CLI pode ser utilizado para impulsionar a configuração do ambiente em todos os cenários, integra-se nos Ambientes de Implementação do Azure para proporcionar segurança melhorada, IaC integrado, controlo de ambiente, separação de preocupações e configuração simplificada do CD.

Assim que tiver um conjunto de modelos, as oportunidades potenciais de desenvolvimento podem utilizar estas ferramentas de linha de comandos ou outras experiências de utilizador integradas para estruturar os respetivos conteúdos para as respetivas aplicações. No entanto, uma vez que os programadores podem não ter permissão para criar repositórios ou outros conteúdos a partir dos seus modelos, esta é também mais uma oportunidade para utilizar fluxos de trabalho/pipelines acionados manualmente e parametrizados. Pode configurar entradas para que o seu sistema CI/CD crie tudo, desde um repositório a uma infraestrutura em nome deles.

Manter-se à direita e acertar

No entanto, para ajudar a dimensionar, estes modelos de aplicação devem referenciar blocos modulares centralizados sempre que possível (por exemplo, modelos IaC ou até fluxos de trabalho/pipelines CI/CD). Na verdade, pode considerar que tratar estes blocos modulares centralizados como a sua própria forma de começar modelos corretos é uma estratégia eficaz para resolver alguns dos problemas que identificou.

Cada um destes modelos individuais pode ser aplicado não só a novas aplicações, mas também aos modelos existentes que pretende atualizar como parte de uma campanha get right para implementar diretrizes atualizadas ou melhoradas. Melhor ainda, esta centralização ajuda-o a manter as aplicações novas e existentes à direita, permitindo-lhe evoluir ou expandir as suas melhores práticas ao longo do tempo.

Conteúdo do modelo

Recomendamos que considere as seguintes áreas ao criar modelos.

Área	Detalhes
Código fonte de exemplo suficiente para impulsionar padrões de aplicações, SDKs e utilização de ferramentas	Inclua código e configuração para orientar os programadores para idiomas recomendados, modelos de aplicações e serviços, APIs, SDKs e padrões de arquitetura. Certifique-se de que inclui código para rastreio distribuído, registo e observabilidade com as suas ferramentas de eleição.
Criar e implementar scripts	Forneça aos programadores uma forma comum de acionar uma compilação e uma implementação local/sandbox. Inclua a configuração de depuração no IDE/editor para que as suas ferramentas escolham utilizá-las. Esta é uma forma importante de evitar dores de cabeça de manutenção e evitar que a CI/CD esteja dessincronizada. Se o motor de modelação for opinado como o Azure Developer CLI, poderão já existir comandos que pode utilizar.
Configuração para CI/CD	Forneça fluxos de trabalho/pipelines para criar e implementar aplicações com base nas suas recomendações. Tire partido de fluxos de trabalho/ pipelines centralizados, reutilizáveis ou modelos para ajudar a mantê-los atualizados. Na verdade, estes fluxos de trabalho/pipelines reutilizáveis podem ser modelos corretos. Não se esqueça de considerar uma opção para acionar manualmente estes fluxos de trabalho.
Infraestrutura como recursos de código	Forneça configurações IaC recomendadas, incluindo referências a módulos geridos centralmente ou itens de catálogo para garantir que qualquer configuração de infraestrutura segue as melhores práticas do get-go. Estas referências também podem ajudar as equipas a manterem-se certas à medida que o tempo passa. Combinado com fluxos de trabalho/pipelines, também pode incluir IaC ou EaC para aprovisionar praticamente tudo.
Segurança e política como recursos de código	O movimento DevSecOps também moveu a configuração de segurança para o código, o que é ótimo para modelos. Algumas políticas como artefactos de código também podem ser aplicadas ao nível da aplicação. Inclua como tudo, desde ficheiros como CODEOWNERS até à configuração de análise como dependabot.yaml no GitHub Advanced Security. Forneça fluxos de trabalho agendados/execuções de pipelines para análises com algo como o Defender para a Cloud , juntamente com execuções de testes de ambiente. Isto é particularmente importante para a segurança da cadeia de fornecimento e certifique-se de que tem em conta as imagens de contentor , além dos pacotes de aplicações e do código. Estes passos ajudam as equipas de desenvolvimento a manterem-se corretas.
Observabilidade, monitorização e registo	Parte da ativação self-service é proporcionar visibilidade fácil às aplicações depois de implementadas. Além da infraestrutura de runtime, certifique-se de que inclui a configuração para observabilidade e monitorização. Na maioria dos casos, existe um aspeto iaC para configurar (por exemplo, implementação de agente, instrumentação) enquanto noutros pode ser outro tipo de artefacto de código config-as (por exemplo, monitorizar dashboards para Aplicação Azure Insights). Por fim, não se esqueça de incluir código de exemplo de código para rastreio distribuído, registo e observabilidade com as suas ferramentas de eleição.
Configuração do ambiente de codificação	Inclua ficheiros de configuração para codificar linters, formatters, editores e IDEs. Inclua scripts de configuração juntamente com ficheiros de virtualização de áreas de trabalho ou de estação de trabalho, como devcontainer.json, devbox.yaml, Dockerfiles focados no programador, ficheiros Docker Compose ou Vagrantfiles.
Configuração de teste	Forneça ficheiros de configuração para testes de unidades e mais aprofundados com os seus serviços preferenciais, como Microsoft Playwright Testing para IU ou Teste de Carga do Azure.
Configuração da ferramenta de colaboração	Se a gestão de problemas e o sistema de gestão de controlo de código fonte suportarem modelos de tarefa/problema/PR como código, inclua-os também. Nos casos em que é necessária mais configuração, pode fornecer opcionalmente um fluxo de trabalho/pipeline que atualiza os seus sistemas com uma CLI ou API disponível. Isto também lhe permite configurar outras ferramentas de colaboração, como o Microsoft Teams ou o Slack.

Refinar a plataforma de aplicações