Ciclo de vida do desenvolvimento
A estratégia de ciclo de vida de desenvolvimento fornece as principais considerações de projeto e recomendações para repositório, ramificação, compilações automatizadas, implantação e estratégia de reversão durante a criação automática da zona de aterrissagem.
Estratégia do repositório
Considerações de design
Considere adotar um sistema de controle de versão como o Git para fornecer à sua equipe flexibilidade no compartilhamento e gerenciamento de código.
- O Git é o sistema de controle de versão padrão da indústria. É um sistema de controle de versão distribuído, onde sua cópia local do código é uma versão completa do repositório.
Entenda a estrutura do repositório mono-repo versus multirepo.
- Em estruturas mono-repo, todo o código-fonte vive em um único repositório.
- Em estruturas multirepo, todos os projetos são organizados em repositórios separados.
Escolha uma configuração de visibilidade adequada ao conteúdo do repositório.
- Os repositórios públicos podem ser acedidos anonimamente.
- Os repositórios privados exigem que os usuários tenham acesso ao repositório e entrem para acessar os serviços.
- Você pode definir visibilidade pública e privada para Projetos de DevOps do Azure e repositórios do GitHub.
Considere definir permissões de repositório que ajudam a controlar quem pode contribuir com seu código-fonte e gerenciar outros recursos.
- Você pode definir permissões de repositório para o Azure DevOps e o GitHub.
Considere usar a implantação de recursos de Infraestrutura como Código (IaC) no Azure. O IaC permite gerenciar a infraestrutura em um modelo declarativo, ajudando a reduzir o esforço de configuração, garantir a consistência entre as implantações e evitar a configuração manual do ambiente.
O Azure fornece suporte para IaC para Zonas de Desembarque através de:
Recomendações de design
Use o Git como um sistema de controle de versão.
Usar repositórios privados ao criar Zonas de Aterrissagem do Azure
Use repositórios públicos ao compartilhar informações não confidenciais, como exemplos de automação, documentação pública e material de colaboração de código aberto.
Adote uma abordagem IaC para implantar, gerenciar, governar e dar suporte a recursos de nuvem.
Estratégia de sucursais
Considerações de design
Considere o uso de uma estratégia de filial que permita que as equipes colaborem melhor e gerenciem com eficiência o controle de versão.
Considere o uso de convenções de nomenclatura específicas para suas filiais.
Considere o uso de permissões de filial para controlar os recursos do usuário.
Considere o uso de políticas de filiais para ajudar suas equipes a proteger ramos importantes de desenvolvimento. Políticas que podem ajudar a impor a qualidade do código e os padrões de gerenciamento de alterações. Exemplos de políticas de sucursais incluem:
- Sempre usando solicitações pull para mesclar alterações em ramificações importantes.
- Exigindo um número mínimo de revisores para solicitações pull.
- Incluindo automaticamente revisores de código.
- A verificação de itens de trabalho vinculados permite que você mantenha a rastreabilidade.
- A verificação da resolução de comentários valida se todos os comentários de RP foram resolvidos.
- Limitar os tipos de mesclagem.
A adoção de uma estratégia de pull request pode ajudá-lo a manter o controle das alterações de código mescladas em ramificações.
- Defina uma estratégia de mesclagem.
- As solicitações pull devem ser simples, com o número de arquivos reduzido ao mínimo para ajudar os revisores a validar confirmações e alterações de forma mais eficiente.
- As solicitações pull devem ter títulos e descrições claras para que os revisores saibam o que esperar ao revisar o código.
- Você pode usar modelos de solicitação pull.
- Você pode excluir ramificações de origem depois que as solicitações pull forem concluídas, o que lhe dá mais controle e melhor gerenciamento de ramificações.
Recomendações de design
Adote um modelo de desenvolvimento baseado em tronco, no qual os desenvolvedores se comprometem com uma única ramificação. Este modelo facilita a integração contínua. Todo o trabalho de recurso é feito no tronco, e quaisquer conflitos de mesclagem são resolvidos quando a confirmação acontece.
Peça às suas equipes que definam e usem convenções de nomenclatura consistentes para filiais para identificar o trabalho realizado.
Defina permissões para controlar quem pode ler e atualizar o código em uma ramificação do seu repositório Git. Você pode definir permissões para usuários individuais e para grupos.
Definir políticas de filial:
- Exija o uso de solicitações pull para mesclagens de ramificação na ramificação principal.
- Exija um número mínimo de revisores para solicitações pull.
- Redefina todos os votos de aprovação para remover todos os votos de aprovação, mas mantenha os votos para rejeitar ou aguardar sempre que uma ramificação de origem mudar.
- Inclua automaticamente revisores de código.
- Verifique a resolução dos comentários.
Defina o squash como estratégia de mesclagem, que permite condensar o histórico do Git de ramificações de tópicos quando você conclui solicitações pull. Em vez de adicionar cada confirmação em uma ramificação de tópico ao histórico da ramificação padrão, uma mesclagem de squash adiciona todas as alterações de arquivo a uma única nova confirmação na ramificação padrão.
Compilações automatizadas
Considerações de design
Considere a implementação da Integração Contínua (CI). A CI envolve a fusão de todo o código do desenvolvedor em uma base de código central em um cronograma regular e a execução automática de compilações padrão e processos de teste.
Considere o uso de gatilhos de IC:
- Azure Repos Git. Você pode configurar ramificações, caminhos e tags como gatilhos para executar uma compilação de CI.
- GitHub. Você pode configurar ramificações, caminhos e gatilhos de tags para executar uma compilação de CI.
Considere incluir testes de unidade IaC em seu processo de compilação para validar a sintaxe.
- O kit de ferramentas de teste de Modelos ARM verifica se um modelo segue as práticas recomendadas.
- O Bicep linter verifica os arquivos Bicep em busca de erros de sintaxe e violações de práticas recomendadas.
Considere incluir testes de unidade em seu processo de compilação de aplicativos. Analise as tarefas disponíveis para o Azure DevOps Pipeline.
Use conexões de serviço do Azure DevOps ou segredos do GitHub para gerenciar conexões com o Azure. Cada conexão deve ter o acesso de privilégio correto aos recursos do Azure.
Considere usar segredos do Cofre de Chaves do Azure para armazenar e gerenciar informações confidenciais, como senhas, chaves de API, certificados.
Os agentes do Azure DevOps podem ser auto-hospedados ou hospedados pela Microsoft.
- A manutenção e as atualizações são cuidadas quando você usa agentes hospedados pela Microsoft. Sempre que um trabalho de compilação é executado, uma nova máquina virtual é criada.
- Você configura e gerencia agentes auto-hospedados por conta própria para executar trabalhos de compilação.
Recomendações de design
Use o CI para automatizar compilações e testes de código sempre que um membro da equipe confirmar alterações no controle de versão.
Inclua testes de unidade para IaC e código de aplicativo como parte do seu processo de compilação.
Se possível, use pool hospedado pela Microsoft em vez de pools auto-hospedados, pois eles oferecem isolamento e uma VM limpa para cada execução de pipeline.
Quando você conecta o Azure DevOps ou o GitHub ao Azure por meio de conexões de serviço ou segredos do GitHub, certifique-se de sempre definir o escopo para que eles possam acessar apenas os recursos necessários.
Use segredos do Cofre de Chaves para evitar codificar informações confidenciais, como credenciais (senhas de usuário da máquina virtual), certificados ou chaves. Em seguida, use segredos como variáveis em seus trabalhos de compilação e lançamento.
Estratégia de implantação
Considerações de design
Considere o uso de Entrega Contínua (CD). O CD envolve a criação, o teste, a configuração e a implantação de uma compilação para um ambiente.
Considere o uso de ambientes. Os ambientes permitem direcionar uma coleção de recursos de um trabalho de entrega. Exemplos de nomes de ambientes comuns incluem:
- Programador
- Teste
- Perguntas e Respostas
- Processo de teste
- Produção
Considere o uso do IaC como parte de sua estratégia para validar e confirmar a pré-implantação de alterações.
Recomendações de design
Use o CD para garantir que o código esteja sempre pronto para ser implantado, criando, testando e implantando código automaticamente em ambientes semelhantes aos de produção. Adicione entrega contínua para criar uma integração completa de CI/CD que ajuda a detetar defeitos de código o mais cedo possível e garante que você possa lançar rapidamente atualizações devidamente testadas.
Use ambientes como parte de sua estratégia de implantação. Os ambientes oferecem benefícios como:
- Histórico de implementações
- Rastreabilidade de autorizações e itens de trabalho
- Integridade do recurso de diagnóstico
- Segurança
Inclua verificações de pré-implantação do IaC para que você possa visualizar as alterações e ver detalhes sobre se um recurso foi criado, modificado ou excluído.
Estratégia de reversão
Considerações de design
Considere a criação de um plano de reversão. Reverter uma implantação envolve reverter a implantação para um estado em boas condições e fornece uma capacidade crucial de recuperação de uma implantação com falha.
Considere usar desfazer alterações no Git se precisar reverter alterações em uma confirmação, descartar alterações ou redefinir uma ramificação para um estado anterior.
Recomendações de design
- Adote o uso de desfazer alterações no Git quando precisar reverter alterações em arquivos confirmados, descartar alterações não confirmadas ou redefinir uma ramificação para um estado anterior.