Aplicar sistemas de engenharia de software

Melhorar o autosserviço 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 apenas são familiares para você e seus clientes internos, mas também podem permitir uma ampla gama 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 ampla variedade de cenários de autoatendimento e detalhes sobre como encapsular as práticas recomendadas em modelos que ajudam você a começar certo e permanecer certo.

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

Os sistemas de engenharia são um aspeto crítico da sua plataforma interna de desenvolvedores. As plataformas internas de desenvolvimento são construídas a partir dos principais princípios de DevOps e DevSecOps para reduzir a carga cognitiva para todos os participantes.

O DevOps combina desenvolvimento e operações para unir pessoas, processos e tecnologia no planejamento, desenvolvimento, entrega e operações de aplicativos. Destina-se a melhorar a colaboração em 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 feedback. O DevSecOps se encaixa nesse loop com práticas de segurança contínuas durante todo o processo de desenvolvimento de aplicativos.

As seções a seguir se concentram em melhorias atribuídas mais diretamente ao movimento de engenharia da 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á tem 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 dará suporte a uma constelação de ferramentas diferentes desde o início. Definir um conjunto de caminhos pavimentados dentro desta constelação de ferramentas é mais eficaz e proporciona 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 espera-se que gerenciem, mantenham e paguem por suas ferramentas separadamente, sem deixar de cumprir quaisquer requisitos de conformidade. Isso fornece uma maneira de alimentar novas ferramentas no ecossistema sem interrupções, uma vez que 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 seguir seu próprio caminho, mas faça isso na direção em que estamos indo... Você pode mudar o que quiser, mas isso se torna sua responsabilidade. Você é dono das mudanças – você é dono das facas afiadas. - Mark, responsável de engenharia de plataforma, grande empresa multinacional europeia de retalho

Dado que um dos principais objetivos da engenharia de plataforma é mudar para uma mentalidade de produto onde você fornece 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 outros na organização. Isto conduz a um conjunto de caminhos totalmente pavimentados e dourados, enquanto outros são apenas parcialmente pavimentados. Nos casos em que não há requisitos exclusivos, o desenvolvimento de trabalho extra que as equipas realizam naturalmente faz com que elas queiram mudar para uma via suportada ao longo do tempo.

Se você preferir uma estratégia de consolidação, migrar aplicativos existentes pode ser mais trabalhoso do que você espera, portanto, para começar, você provavelmente vai querer se concentrar no aspeto inicial certo deste espaço e se concentrar em novos projetos. Isto proporciona o seu primeiro caminho pavimentado, enquanto tudo o que existe é inerentemente não pavimentado. As equipes de desenvolvimento no caminho não pavimentado podem considerar a mudança assim que seu novo caminho pavimentado mostrar seu valor para a organização. Nesse ponto, você pode executar uma campanha certa para colocar todos no estado desejado por meio de comunicação bidirecional, já que as equipes de desenvolvimento veem isso como um benefício e não como um imposto. Durante a campanha, as equipes de engenharia da 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 obrigar o uso de seus caminhos pavimentados. A maneira mais eficaz de implantar caminhos pavimentados é enfatizar o que as equipes obtêm deles, em vez de por meio da adoção forçada. Como sua plataforma interna de desenvolvedores se concentra em fazer essas mesmas equipes felizes, a pressão de orçamento e tempo para valor sobre os líderes individuais cuida do resto. Obtenha as campanhas certas para facilitar conversas bidirecionais sobre a melhor maneira para aqueles que estão em um caminho não pavimentado fazerem a transição.

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

Parte da criação de seu primeiro caminho pavimentado deve ser estabelecer seus principais produtos de automação para desenvolvedores. Isso é importante 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 apontam 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 usar a infraestrutura como código (IaC) para criar ou atualizar a infraestrutura de aplicativo necessária como parte do pipeline de CD.

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

O que você escolhe é impulsionado pelo seu conjunto de habilidades IaC existentes e pelos detalhes da sua plataforma de aplicativo 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 mistura dos dois. Independentemente disso, tornar-se bem versado nas práticas de IaC pode ajudá-lo a aprender padrões que se aplicam a outros cenários de automação.

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

Para gerenciar e dimensionar o IaC entre aplicativos, você deve publicar seus artefatos do IaC centralmente para reutilização. Por exemplo, você pode usar módulos Terraform em um registro, módulos Bicep,receitas Radius ou gráficos Helm armazenados em um registro OCI Artifact nativo da nuvem, como Azure Container Registry (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 fornecer suporte adicional para outros tipos de recursos do Azure. Outras ferramentas, como o Crossplane, suportam recursos em várias nuvens. Isso permite que você use gráficos Helm centralizados ou comuns em algo como ACR para uma ampla variedade de cenários.

Centralizar o IaC melhora a segurança, oferecendo um melhor controle sobre quem pode fazer atualizações, já que elas não são mais armazenadas com o código do aplicativo. Há 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 de plataforma fazem as alterações necessárias. Os desenvolvedores também se beneficiam desses blocos de construção, uma vez que não precisam criar modelos IaC completos e se beneficiam automaticamente das práticas recomendadas codificadas.

O formato IaC escolhido depende do seu 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 do Radius OSS são mais opinativos do que usar o Kubernetes diretamente, mas também simplificam a experiência do desenvolvedor. Para saber mais sobre os prós e contras de diferentes modelos, consulte Descrever tipos de serviço de nuvem. Independentemente disso, referenciar IaC centralizado e gerenciado em vez de ter definições completas em sua árvore de origem tem benefícios significativos.

Armazenar quaisquer identidades ou segredos de provisionamento necessários de uma forma que os desenvolvedores não possam acessá-los diretamente cria a base essencial para a governança. Por exemplo, considere esta ilustração sobre a separação de funções que você pode obter usando os Ambientes de Implantação do Azure (ADE).

Aqui, engenheiros de plataforma e outros especialistas desenvolvem IaC e outros modelos e os colocam em um catálogo. As operações podem, então, adicionar identidades gerenciadas e assinaturas 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 sequer ter acesso à assinatura subjacente ou às identidades necessárias para fazê-lo. Quer você use algo como ADE ou não, seu sistema de entrega contínua de escolha pode ajudá-lo a atualizar a infraestrutura com segurança, separando segredos e fornecendo conteúdo IaC de locais que os desenvolvedores não podem acessar ou modificar por conta própria.

Habilite o autosserviço em cenários além da entrega contínua de aplicativos

Embora os conceitos de CI e CD estejam ligados ao desenvolvimento de aplicativos, muitas das coisas que seus clientes internos desejam provisionar não estão diretamente ligadas 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 uma delas, 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 sistemas de controle de versão e processos de pull request?
• Quais são os requisitos de auditoria para os processos? Estes diferem dos requisitos de auditoria do seu sistema de controle de origem?
• Existem processos com os quais você pode começar 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 alvos potenciais a serem automatizados primeiro.

Use o padrão tudo como código

Uma das coisas boas sobre o Git, além de sua ubiquidade, é que ele pretende ser uma fonte segura e auditável de informações. Além do histórico de confirmação e dos controles de acesso, conceitos como pedidos de pull e proteção de ramificação oferecem uma maneira de estabelecer revisores específicos, um histórico de conversas e/ou verificações automatizadas que devem ser concluídas antes de serem integradas na ramificação principal. Quando combinado com mecanismos de tarefas flexíveis como os encontrados em sistemas 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 qualquer coisa 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 auxilia a repetibilidade por meio de modelos e simplifica o autosserviço do desenvolvedor. Vamos passar por vários exemplos de como isso pode funcionar.

Aplique padrões IaC a qualquer infraestrutura

Embora o 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, clusters Kubernetes partilhados com o Flux instalado, provisionar algo como DataDog que são utilizadas por várias equipas e aplicações, ou até mesmo configurar as 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 ou Terraform, até gráficos Helm e outros formatos nativos do Kubernetes). Uma equipe de operações ou outro conjunto de administradores é o proprietário do repositório, e os desenvolvedores (ou sistemas) podem enviar solicitações pull (PRs). Uma vez que esses RPs são mesclados 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 a ilustração a seguir que mostra as Ações do GitHub, o IAC e as identidades de implantação alojadas nos 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 expandir 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árias 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 os RPs não têm acesso direto a esses segredos, ele fornece uma maneira para os desenvolvedores iniciarem com segurança ações que eles mesmos não têm permissão direta para fazer. Isso permite que você siga o princípio de menor privilégio e, ao mesmo tempo, ofereça aos desenvolvedores uma opção de autosserviço.

Rastreie a infraestrutura provisionada

Ao começar a dimensionar essa abordagem, pense em como você deseja controlar 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 de tudo como código fornece uma fonte de informações a ser aproveitada para sintetizar um inventário da infraestrutura provisionada. O seu fornecedor de serviços também pode ser uma boa fonte dessas informações que pode consultar. Por exemplo, os Ambientes de Implantação do Azure incluem recursos de rastreamento 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 a 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 surgimento do conceito política como código. Aqui, os arquivos de configuração em um repositório de controle de origem podem ser usados para fazer coisas como verificar a segurança da unidade ou aplicar políticas de infraestrutura.

Muitos produtos diferentes e projetos de código aberto adotaram 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 do 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.

O PR torna-se uma boa experiência de utilizador de autoatendimento padrão para vários processos, especialmente quando se está a começar. Os processos naturalmente ganham os benefícios de segurança, auditabilidade 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.

Equipas como código-fonte

Um exemplo de aplicar tudo como código aos seus próprios cenários é o padrão "teams as code". 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 desintegração da central de serviços que são impulsionados pela necessidade de desenvolvedores de sistemas e operadores acessarem seus próprios conceitos de agrupamento, usuário e acesso. Os processos manuais de balcões de serviço são um risco potencial de segurança porque é possível superprovisionar o acesso. Ao usar as equipes como padrão de código, a combinação de Git e PRs pode habilitar o autosserviço a partir 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 sua sofisticada implementação de Direitos para você experimentar ou adotar. Embora a postagem do blog descreva todos os direitos dos 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 estar representadas em um organograma de funcionários e envolvem ferramentas ou serviços proprietários que podem complicar a integração ou desintegração 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, Microsoft Entra ID) para logon único (SSO).
• Você usa grupos de provedores de identidade (por exemplo, grupos Entra) em todos os 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. Os proprietários ou aprovadores para modificações da equipa também podem ser armazenados neste mesmo local (por exemplo, através 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 para esses arquivos são feitas através de solicitações pull. Isso vincula conversas e participantes relacionados sobre a solicitação de comprometimento do Git para auditabilidade.
• Leads e usuários individuais podem fazer RPs para adicionar ou remover pessoas, e leads de desenvolvimento e outras funções podem criar novas equipes usando RPs com um novo arquivo de equipe de um modelo.
• Sempre que um RP é fundido em principal, um sistema de CI/CD vinculado ao repositório atualiza o sistema do provedor de identidade e todos os sistemas a jusante, conforme apropriado.

Especificamente, o sistema CI/CD:

• Usa a API apropriada do sistema do provedor de identidade 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 o conceito de agrupamento de sistemas a um grupo de provedores de identificação para cada função (por exemplo, GitHub e Azure DevOps). Isso pode resultar numa relação de um para muitos entre a sua equipa e o sistema a jusante 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 dos 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 de 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á usa algo como o gerenciamento de direitos do Entra, talvez você possa 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 a integração com qualquer sistema downstream são mantidos no sistema CI/CD (por exemplo, em Ações do GitHub ou Pipelines do Azure) ou em algo como o Cofre de Chaves do Azure.

Usar fluxos de trabalho parametrizados manuais ou acionados 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 de usuário que deseja usar para impulsionar a experiência de autoatendimento.

Felizmente, a maioria dos sistemas de CI, incluindo Ações do GitHub e Pipelines do Azure, tem a capacidade de configurar um fluxo de trabalho com entradas que você pode acionar manualmente por meio de suas UIs ou CLIs. Dado que os desenvolvedores e funções relacionadas com operações provavelmente já estão familiarizados com estas experiências do utilizador, os gatilhos manuais podem aumentar o padrão de tudo como código para permitir a automação para atividades (ou tarefas) que não têm uma representação de arquivo natural ou devem ser totalmente automatizadas sem necessitar de um processo de PR.

Seu sistema de CI pode permitir que você opte por acionar esses fluxos de trabalho ou pipelines a partir de suas próprias experiências de usuário por meio de uma API. Para as Ações do GitHub, a chave para fazer isso funcionar é a API REST de Ações para disparar um evento de despacho de fluxo de trabalho para iniciar 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 acionado manualmente ou por meio de uma API, cada fluxo de trabalho pode suportar 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 de portal como Backstage.io interagem com as Ações do GitHub.

O fluxo de trabalho ou sistema de trabalho do seu sistema CI/CD sem dúvida rastreia as atividades, relata o status 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 quaisquer 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 no Microsoft Entra ID) para sistemas downstream.

Você terá visibilidade sobre quem inicia as solicitações em seu sistema de CI/CD, mas deve avaliar se essas informações são suficientes e certificar-se de que suas configurações de retenção de CI/CD estejam em conformidade com os 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 do Slack , que pode permitir que você mantenha qualquer pessoa que envie uma solicitação para obter atualizações de status e o canal fornece um registro informal do que aconteceu. Esses mesmos mecanismos de fluxo de trabalho geralmente já são projetados para se integrar com ferramentas de operações para ampliar ainda mais a utilidade desses padrões.

Em resumo, você pode implementar alguma automação usando arquivos armazenados em um repositório de controle de 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 desenvolvedores podem usar essa abordagem como ponto de partida sem comprometer recursos mais sofisticados ao longo do tempo, consulte Projetar 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 faça a sua primeira pull request. Esta é uma área problemática quando se transferem desenvolvedores entre equipas de funcionalidades e projetos com bastante frequência (por exemplo, em organizações matriciais), é necessário recrutar trabalhadores externos ou se está numa equipa que está em fase de contratação.
• A inconsistência entre os desenvolvedores e com os seus sistemas de CI pode levar a problemas frequentes de "funciona na minha máquina", mesmo para membros experientes da equipa.
• Experimentação e atualização de estruturas, tempos de execução e outros softwares também podem quebrar os ambientes de desenvolvedores existentes e levar a tempo perdido tentando descobrir exatamente o que deu errado.
• Para líderes de desenvolvimento, as revisões de código podem retardar o desenvolvimento, uma vez que 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 têm que 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 dos 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 da máquina 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 da estação de trabalho e foco no Windows

Se você estiver visando o Windows ou quiser fazer a virtualização completa da estação de trabalho (ferramentas de cliente e configurações do sistema operacional do host, além das 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 clientes Windows até o serviço do Windows ou o gerenciamento e manutenção de aplicativos Web de estrutura completa .NET.

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

Se você estiver visando 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 de projetos ou aplicativos.

Crie modelos de aplicação "start right" que incluam a configuração "stay right"

O ponto positivo do padrão de tudo como código é que ele pode manter os desenvolvedores no caminho traçado que você estabeleceu desde o princípio. 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 pode ser menos eficaz. Você também pode querer 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 criar modelos e simplificar a configuração de CI/CD, também fornece um conjunto conveniente de comandos do desenvolvedor. Como a CLI do Desenvolvedor do Azure pode ser usada para impulsionar 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, rastreamento de ambiente, separação de preocupações e configuração simplificada de 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 organizar 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 a partir de seus modelos, essa também é outra oportunidade de usar fluxos de trabalho ou 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.

Permanecer correto e atingir a precisão

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

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 correta para lançar diretrizes atualizadas ou aprimoradas. Melhor ainda, 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 seguintes áreas ao criar modelos.

Conteúdo relacionado

• Centro de recursos de DevOps da Microsoft
• Estrutura segura da cadeia de suprimentos de contêineres
• Arquitetura de linha de base CI/CD com Azure Pipelines
• Refine sua plataforma de aplicativos