Aplicar sistemas de engenharia de software

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

Uma das maneiras mais fáceis de começar a habilitar experiências automatizadas de autoatendimento é reutilizar seus sistemas de engenharia existentes. Esses sistemas não só sã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 fornece dicas para aplicar seus sistemas de engenharia para lidar com uma matriz mais ampla de cenários de autoatendimento e detalhes sobre como encapsular as práticas recomendadas em modelos que ajudam você a começar corretamente e permanecer correto.

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

Os sistemas de engenharia são um aspecto crítico da plataforma de desenvolvedor interno. As plataformas de desenvolvedor internas são baseadas nos principais pilares do DevOps e do DevSecOps para reduzir a carga cognitiva para todos os envolvidos.

O DevOps combina desenvolvimento e operações para unir pessoas, processos e tecnologia em planejamento de aplicativos, desenvolvimento, entrega e operações. O objetivo é melhorar a colaboração em funções historicamente siloed, 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 integra-se neste loop com práticas de segurança contínuas em todo o processo de desenvolvimento de aplicações.

As seções a seguir se concentram 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 de 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 seus caminhos pavimentados desejados

Se você já tiver vários conjuntos de ferramentas que compõem seus sistemas de engenharia, uma decisão inicial a ser tomada é se você deseja 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. 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, pense nos sistemas de engenharia dentro desses caminhos pavimentados, 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 integrar 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 consolidado ao longo do tempo. Como disse um líder de engenharia de plataforma:

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

Dado que um objetivo fundamental para a engenharia de plataforma é mudar para uma mentalidade de 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 entrada 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 fato de as equipes assumirem naturalmente trabalho extra faz com que desejem migrar para um caminho suportado ao longo do tempo.

Se você preferir uma estratégia de consolidação, a migração de aplicativos existentes pode ser mais trabalhosa do que você espera, portanto, para começar, é provável que você queira se concentrar em iniciar corretamente nesse espaço e focar em novos projetos. Isso fornece seu primeiro caminho pavimentado, enquanto tudo o que existe é inerentemente não pavimentado. As equipes de desenvolvimento que estão no caminho não pavimentado podem considerar uma transferência assim que o novo caminho pavimentado mostrar seu valor para a organização. Nesse ponto, você pode implementar uma campanha de alinhamento para garantir que todos alcancem o estado desejado através da comunicação bidirecional, já que as equipes de desenvolvimento veem isso como um benefício em vez de uma taxa. 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, evite exigir o uso de seus caminhos pavimentados. A maneira mais eficaz de implantar caminhos pavimentados é enfatizar o que as equipes ganham com eles em vez de uma adoção obrigatória. Como sua plataforma interna de desenvolvedores se concentra em fazer essas mesmas equipes felizes, a pressão de orçamento e de tempo para obter valor sobre líderes individuais se encarrega do restante. Obtenha as campanhas corretas e, em seguida, ofereça uma via para conversas bidirecionais sobre a melhor maneira para aqueles em um caminho não pavimentado de realizar a mudança.

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

Parte da criação de seu primeiro caminho pavimentado deve ser estabelecer seus principais produtos de automação para desenvolvedores. Elas são importantes à medida que 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 foi implementado, os problemas identificados durante o planejamento provavelmente apontam para problemas que a CI (integração contínua) e o CD (entrega contínua) 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 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, considere usar 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 o GitHub Actions para atualizar a infraestrutura e implantar no Serviço de Kubernetes do Azure: uma usando implantações baseadas em push e uma implantação baseada em pull (GitOps).

O que você escolhe é 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 mais 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 nas práticas de IaC pode ajudá-lo a aprender padrões que se aplicam a outros cenários de automação.

Centralizar IaC em um catálogo ou registro para escalar e melhorar a segurança

Para gerenciar e dimensionar o IaC entre aplicações, você deve publicar seus artefatos de IaC de forma centralizada 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 de artefato OCI nativo da nuvem, como o Registro de Contêiner Azure (ACR),o 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 o Crossplane, dão suporte a recursos em várias nuvens. Isso permite que você use gráficos centralizados ou comuns do Helm em algo como o ACR para uma matriz mais ampla de cenários.

Centralizar a 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.

Qual formato de IaC você escolher 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 projeto de incubação experimental recente 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 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 estabelece os alicerces 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á-las para provisionamento.

Os desenvolvedores ou o 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 mesmo ter acesso à assinatura ou identidades subjacentes necessárias para isso. Se você usa algo como o ADE ou não, o sistema de entrega contínua que você escolheu pode ajudá-lo a atualizar a infraestrutura de forma segura e protegida, separando segredos e originando conteúdo IaC de locais que os desenvolvedores não podem acessar ou modificar individualmente.

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 uma infraestrutura compartilhada, criando um repositório, ferramentas de provisionamento e muito mais.

Para entender onde isso pode ajudar, pense no local em que você tem processos manuais ou baseados em service desk. Para cada um, pense nessas perguntas:

• Com que frequência esse processo acontece?
• O processo é lento, propenso a erros ou requer um trabalho significativo a 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? Elas diferem dos requisitos de auditoria do sistema de controle do código-fonte?
• Há 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 destinos potenciais para automatizar primeiro.

Usar o padrão "tudo como código"

Uma das coisas boas sobre o Git, além de sua onipresença, é 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 solicitações de pull e proteção de ramificação fornecem uma maneira de estabelecer revisores específicos, um histórico de conversas e ou verificações automatizadas que devem passar antes de se mesclar no branch principal. Quando combinado com mecanismos de tarefas flexíveis, como os encontrados em sistemas de CI/CD, você tem uma estrutura de automação segura.

A ideia por trás de tudo como código é que você pode transformar quase tudo em um arquivo em um repositório Git seguro. 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 talvez você queira provisionar e configurar, não apenas aqueles vinculados a um aplicativo específico. Por exemplo, clusters Kubernetes compartilhados com o Flux instalado, provisionando algo como DataDog, que é utilizado 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 e separado, protegido, que abriga arquivos que indicam o que deve ser provisionado e configurado (nesse caso, qualquer coisa, desde Bicep ou Terraform até charts 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 (PRs). Depois que esses PRs são mesclados no branch principal por esses administradores, as mesmas ferramentas de CI/CD usadas durante o desenvolvimento de aplicativos podem entrar em ação para processar as alterações. Considere a ilustração a seguir que mostra GitHub Actions, IaC e identidades de implantação localizados em Azure Deployment Environments.

Se você já estiver usando uma abordagem do GitOps para implantação de aplicativos, poderá reutilizar essas ferramentas também. A combinação de 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ção 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 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 as PRs não têm 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ê siga o princípio do privilégio mínimo, ao mesmo tempo em que oferece aos desenvolvedores uma opção de autoatendimento.

Monitorar 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 as URIs específicas 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 para acessar e sintetizar um inventário de infraestrutura provisionada. Seu provisionador também pode ser uma boa fonte dessas informações que você pode utilizar. 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 do desenvolvedor.

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 à ascensão 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 a verificação de segurança da unidade ou aplicar políticas de infraestrutura.

Muitos produtos diferentes e projetos de software livre adotaram essa abordagem, incluindo Azure Policy, Open Policy Agent, GitHub Advanced Security e GitHub CODEOWNERS, 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.

Utilize 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 acionamento de fluxos de trabalho em qualquer sistema downstream.

A PR se torna uma boa experiência de usuário de autosserviço padrão para vários processos diferentes, especialmente quando se 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.

Equipes como código

Um exemplo de aplicação de 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 composição da equipe e, em alguns casos, ferramentas para desenvolvedores e concessões de serviço em uma ampla variedade de sistemas. Esse padrão elimina os processos de onboarding e offboarding manuais no service desk que são impulsionados pela necessidade de desenvolvedores e operadores de sistemas acessarem seus próprios conceitos de agrupamento, usuário e acesso. Processos manuais das mesas de serviço são um risco potencial de segurança porque é possível superprovisionar o acesso. Ao usar o padrão de equipes como código, a combinação de Git e PRs pode possibilitar o autoatendimento 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 direitos. O GitHub também abriu o código-fonte da sua sofisticada implementação de Entitlements para você testar ou incorporar. Embora a postagem no blog descreva todos os direitos dos funcionários, você pode aplicar o conceito de equipes como código a cenários de equipe de desenvolvimento com escopo mais restrito. Essas equipes de desenvolvimento podem não ser representadas em um organograma e envolvem ferramentas ou serviços proprietários que podem complicar a integração ou a desvinculaçã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:

Neste exemplo:

• Cada sistema envolvido foi configurado para usar seu provedor de identidade (por exemplo, Microsoft Entra ID) para SSO (logon único).
• Você usa grupos de provedores de identidade (por exemplo, grupos Entra) em todos os sistemas para gerenciar a participação com base em funções, a fim de reduzir a complexidade e manter a auditoria centralizada.

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

• Um repositório Git centralizado 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 responsáveis ou aprovadores por mudanças na equipe também podem ser armazenados neste mesmo local (por exemplo, via 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 os usuários).
• Todas as atualizações desses arquivos são feitas por meio de solicitações de pull. Isso vincula conversas e participantes relacionados na solicitação de confirmação do Git para auditoria.
• Clientes potenciais e individuais podem fazer PRs para adicionar ou remover pessoas, e os clientes potenciais de desenvolvimento e outras funções podem criar novas equipes usando PRs com um novo arquivo de equipe de um modelo.
• Sempre que uma PR é mesclada na principal, um sistema de CI/CD vinculado ao repositório atualiza o sistema de provedor de identidade e todos os sistemas downstream conforme apropriado.

Especificamente, o sistema de CI/CD:

• Usa a API do sistema de 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, nada 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 em uma relação um-para-muitos entre sua equipe e o sistema downstream para representar uma função.
• (Opcionalmente) Usa APIs para cada sistema downstream para implementar a lógica de permissões vinculada ao mecanismo de agrupamento do sistema.
• Usa uma API para atualizar um armazenamento de dados restrito com os resultados (incluindo associar as IDs das equipes do sistema downstream) que podem ser consumidos por qualquer um dos seus sistemas internos. Você também pode armazenar associações para diferentes representações do sistema de IDs de usuário para o mesmo usuário/conta do provedor de identidade aqui, se necessário.

Se sua organização já usa algo semelhante a o gerenciamento de direitos do Entra, você poderá omitir o gerenciamento de membros do grupo nesse 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 integrar a qualquer sistema downstream são mantidos no sistema de CI/CD (por exemplo, no GitHub Actions ou no 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 o GitHub Actions e o 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. Dado que os desenvolvedores e as funções de operações relacionadas provavelmente já estão familiarizados com essas experiências do usuário, 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 exigir um processo de PR.

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

O fluxo de trabalho ou o sistema de tarefas do sistema de CI/CD, sem dúvida, controla atividades, informa o 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 tudo como código. No entanto, uma coisa a ter em mente é que todas as ações executadas por esses fluxos de trabalho ou pipelines parecem uma identidade do sistema (por exemplo, entidade de serviço ou identidade gerenciada no 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 , que podem permitir que você mantenha qualquer pessoa enviando uma solicitação para obter atualizações de status e o canal fornece um registro informal do que aconteceu. Esses mesmos mecanismos de fluxos de trabalho geralmente já são projetados para integrar-se às ferramentas de operações para estender ainda mais a utilidade desses padrões.

Em resumo, você pode implementar algumas automações 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 do desenvolvedor.

Automatizar a configuração de ambientes de codificação do desenvolvedor

Outro problema comum nos sistemas de engenharia é 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 nesta área:

• Em alguns casos, pode levar semanas para um desenvolvedor chegar à sua primeira solicitação de pull. Essa é uma área problemática quando você transfere desenvolvedores entre equipes de funcionalidades e projetos com bastante frequência (por exemplo, em organizações matriciais), precisa treinar contratados ou está em uma equipe em fase de contratação.
• A inconsistência entre desenvolvedores e seus sistemas de CI pode levar a problemas frequentes de "funciona em 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 levar ao tempo perdido tentando descobrir exatamente o que deu errado.
• Para líderes de desenvolvimento, as revisões de código podem retardar o desenvolvimento, pois podem exigir uma alteração de configuração para testes e o desfazer dessas alterações após a conclusão da revisão.
• 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 resolver esses problemas, pense na instalação de ferramentas e utilitários específicos como parte de suas rotas pavimentadas e bem definidas. A configuração do computador 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 para o Windows

Se você estiver com foco em Windows ou quiser realizar a virtualização completa da estação de trabalho (além de configurações específicas do projeto, ferramentas de cliente e configurações do sistema operacional host), 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 gerenciamento e manutenção de aplicativos Web da estrutura completa do .NET.

Virtualização do workspace e direcionamento do Linux

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

Criar modelos de aplicativo com configuração inicial correta que incluam a configuração de manutenção apropriada

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 rapidamente se tornar uma maneira crítica de reutilizar blocos de construção para impulsionar a consistência, promover a padronização e codificar as práticas recomendadas da sua organização.

Para começar, você pode usar algo tão simples quanto um repositório de modelos do GitHub, mas se sua organização seguir um padrão monorepo , isso poderá ser menos eficaz. Você também pode criar modelos que ajudam a configurar algo que não está 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 a CLI do Desenvolvedor do Azure (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 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, 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 estruturar seu 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 pipelines ou fluxos de trabalho 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 fazer referência a blocos de construção centralizados sempre que possível (por exemplo, modelos de IaC ou até mesmo fluxos de trabalho e pipelines de CI/CD). Na verdade, tratar esses blocos de construção centralizados como seus próprios modelos de início correto pode ser uma estratégia eficaz para resolver alguns dos problemas que você identificou.

Cada um desses modelos individuais pode ser aplicado não apenas a novos aplicativos, mas também aos existentes que você pretende atualizar como parte de uma campanha get right para implementar 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 áreas a seguir ao criar modelos.

Conteúdo relacionado

• Centro de recursos de DevOps da Microsoft
• Estrutura de Cadeia de Suprimentos Segura de Contêineres
• Arquitetura de linha de base de CI/CD com o Azure Pipelines
• Refinar sua plataforma de aplicativo