Implantação Contínua no Azure

Implantação contínua (CD) libera automaticamente em produção todas as alterações aprovadas nos testes de CI, sem intervenção manual. A entrega contínua é a versão mais flexível — ela automatiza a implantação até um ambiente de staging e exige um portão de aprovação humana antes da produção. Ambas as práticas são baseadas na mesma infraestrutura de pipeline. No Azure Pipelines, a CD é implementada adicionando estágios de implantação após o estágio de CI, direcionados a ambientes do Azure com portões de aprovação conforme necessário.

Um pipeline completo de CI/CD tem pelo menos três estágios: Build (compilar, testar e publicar o artefato), Implantar em Staging (implantar o artefato em um slot que não seja de produção) e Implantar em Produção (trocar o slot ou implantar após a aprovação). Os estágios passam o artefato adiante por meio do armazenamento de artefatos do pipeline. O estágio de staging executa automaticamente testes de integração ou testes de fumaça; o estágio de produção aguarda a aprovação manual antes de prosseguir.

Use tarefas deployment (não job regulares) para os estágios de implantação. As tarefas de implantação oferecem suporte a estratégias de implantação (runOnce, rolling, canary), acompanham o histórico de implantações por ambiente e precisam fazer referência a ambientes do Azure DevOps. Um ambiente registra quais execuções do pipeline foram implantadas nele, qual versão está atualmente ativa e fornece portões de aprovação, verificações e o status de integridade dos recursos em um único painel.

A tarefa AzureWebApp@1 implanta uma aplicação Web no Azure App Service. Ela oferece suporte à implantação em um slot específico (por exemplo, staging), de pacotes ZIP, imagens Docker ou arquivos JAR/WAR. Depois de implantar em um slot de staging, use a tarefa AzureAppServiceManage@0 para trocar o slot de staging para produção — o padrão de implantação preferido sem tempo de inatividade para o App Service.

Depois de implantar em staging, execute testes de fumaça — um conjunto mínimo de testes que verifica se a implantação foi bem-sucedida e se a aplicação está respondendo corretamente. Os testes de fumaça normalmente chamam endpoints de API essenciais e verificam os códigos de status e o conteúdo da resposta esperados. Se os testes de fumaça falharem, o pipeline será interrompido antes da troca para produção ou da solicitação de aprovação, impedindo que uma versão com falhas chegue aos usuários.

Adicione portões de aprovação aos ambientes do Azure DevOps para exigir aprovação manual antes que as implantações prossigam. Acesse as configurações do ambiente e adicione Approvals — especifique os usuários ou grupos que devem aprovar. Quando o pipeline alcançar uma tarefa de implantação direcionada a esse ambiente, ele será pausado e uma notificação por e-mail será enviada. Os aprovadores podem ver os detalhes da implantação e aprovar ou rejeitar no portal do Azure DevOps ou pelo link no e-mail de notificação.

Implante aplicações conteinerizadas no AKS usando a tarefa KubernetesManifest@0. Essa tarefa aplica manifestos YAML do Kubernetes ao cluster, com suporte integrado a imagePullSecrets e implantações canary. Conecte-se ao cluster do AKS usando uma conexão de serviço do Kubernetes configurada no Azure DevOps. A tarefa usa kubectl apply internamente e aguarda a conclusão da atualização antes de marcar a etapa como bem-sucedida.

Marque imagens de contêiner com o ID da compilação ($(Build.BuildId)) ou o SHA do commit do Git ($(Build.SourceVersion)) para que você possa sempre rastrear um contêiner em execução até a revisão exata do código que o compilou. Evite usar a marca latest em produção — o Kubernetes a armazena em cache e pode não baixar a nova versão. Armazene a marca específica da imagem como uma variável do pipeline e injete-a nos manifestos do Kubernetes no momento da implantação usando envsubst ou sed.

Defina uma estratégia de reversão para as implantações em produção, para que possa se recuperar rapidamente de uma versão com problemas. No App Service, a reversão significa trocar o slot de produção de volta para a versão anterior no ambiente de preparo. No AKS, use kubectl rollout undo. Crie um pipeline de reversão dedicado ou adicione um trabalho de reversão manual que possa ser acionado no portal do Azure DevOps. Documente o procedimento de reversão e pratique-o regularmente — uma reversão não testada não é uma reversão.

Após cada implantação em produção, execute automaticamente uma verificação de monitoramento para confirmar que a nova versão está saudável. Use a verificação de pipeline AzureMonitor@1 para consultar as métricas do Azure Monitor — se as taxas de erro estiverem elevadas após a implantação, bloqueie o avanço do pipeline e acione uma reversão. Envie notificações de implantação para o Microsoft Teams ou o Slack por meio de tarefas de webhook, para que a equipe saiba quando uma implantação for concluída e qual versão está ativa.

Siga estas práticas recomendadas de implantação contínua: implante com frequência (lotes pequenos reduzem o risco), use sinalizadores de recursos para separar a implantação da liberação, automatize todos os portões de qualidade antes da produção, pratique o preparo semelhante à produção para que as diferenças não ocultem erros, monitore as janelas de implantação com verificações automatizadas de integridade e sempre tenha um plano de reversão testado. Um pipeline de CD maduro transforma a implantação em um evento rotineiro, em vez de uma operação altamente estressante.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) apresentados nesta lição.

Nesta lição, você aprendeu que: os pipelines YAML de várias etapas encadeiam as etapas de Build, preparo e Production com passagem de artefatos; os trabalhos de implantação com Environments permitem portões de aprovação e acompanhamento da implantação; e os testes de fumaça após a implantação no ambiente de preparo impedem que versões com problemas cheguem à produção. A seguir, exploraremos o GitHub Actions no Azure.