A seção de estratégias de implantação no exame AZ-400 pergunta: como entregar código com segurança para produção depois que o build e os testes passam? Uma estratégia mal escolhida pode expor milhares de usuários a erros ou transformar uma reversão simples em horas de trabalho. Esta seção aborda cinco padrões para distribuir o risco, os Feature Flags que os controlam no nível de código e o GitOps que gerencia a infraestrutura de forma declarativa.
Como uma loja de roupas trocando de estação — Blue-Green e Recreate
Algumas lojas retiram toda a coleção de inverno antes de montar a coleção de primavera. Outras mantêm dois espaços funcionando ao mesmo tempo e redirecionam os clientes para o novo quando ele está pronto. A implantação funciona como o primeiro caso. Ela derruba a versão antiga primeiro e depois sobe a nova. É a abordagem mais simples, mas o serviço fica completamente fora do ar durante a transição. Pode ser aceitável para ferramentas internas com uma janela de manutenção, mas não é adequado para sistemas de produção com usuários externos.
A implantação mantém dois ambientes idênticos em execução ao mesmo tempo. Blue hospeda a versão atual em produção, enquanto Green recebe a nova versão. Quando Green estiver pronto, um balanceador de carga ou uma entrada DNS muda o tráfego atomicamente para Green. Se algo der errado, você volta para Blue imediatamente. No Azure App Service, esse padrão é implementado com e . O Slot Swap conclui as solicitações de aquecimento antes de mudar o tráfego, eliminando a latência de cold start no momento da transição.
A principal desvantagem é o custo de infraestrutura: manter dois ambientes em paralelo quase dobra os custos. Uma solução prática é escalar o slot Green só durante o período de testes e reduzir Blue logo após o swap.
Como abrir uma torneira aos poucos — Canary e Rolling
Abrir uma torneira de uma vez pode gerar uma pressão excessiva. Abri-la aos poucos permite detectar problemas com antecedência e fechá-la imediatamente se necessário. A implantação funciona da mesma forma. Ela envia apenas uma pequena fração do tráfego (por exemplo, 5%) para a nova versão, monitora as taxas de erro e os tempos de resposta e vai aumentando gradualmente a porcentagem.
No Azure, Canary é implementado configurando percentuais de tráfego nos Deployment Slots do App Service ou ajustando pesos de Ingress no Azure Kubernetes Service (AKS). A chave é conectar alertas do Azure Monitor a condições automáticas de avançar e reverter com base nas métricas.
A implantação substitui instâncias uma de cada vez, em sequência. Como a versão antiga e a nova ficam em execução simultânea por um período, a compatibilidade retroativa da API é estritamente obrigatória. No AKS, os parâmetros e controlam o ritmo da implantação.
| Padrão | Downtime | Custo de infraestrutura | Velocidade de reversão | |--------|----------|-------------------------|------------------------| | Recreate | Sim | Baixo | Lenta | | Blue-Green | Não | Alto | Imediata | | Canary | Não | Médio | Rápida | | Rolling | Não | Baixo | Média |
!Comparação de 4 estratégias de implantação
Como um ensaio clínico de um novo medicamento — Feature Flags e Progressive Delivery
Implantar uma nova funcionalidade não significa que todos os usuários precisam vê-la imediatamente. Ensaios clínicos de medicamentos começam com um grupo pequeno de voluntários e só avançam para a próxima fase quando os resultados são promissores. Um controla se uma funcionalidade está ativa ou inativa em tempo de execução, mesmo que o código já tenha sido implantado. É a ferramenta essencial para separar a implantação do lançamento.
No Azure, você usa com a biblioteca . Os feature flags são armazenados no App Configuration e o aplicativo .NET, Java ou Python os lê em tempo de execução via Azure.Identity. Condições incluem IDs de usuário, porcentagem, localização ou qualquer atributo personalizado. GitHub Feature Flags e LaunchDarkly seguem o mesmo conceito.
combina Canary, Feature Flags e observabilidade: implanta-se o código com o flag desativado e o abre gradualmente enquanto se monitoram as métricas. Quando o experimento termina, a limpeza do código do flag deve fazer parte do pipeline — flags acumulados adicionam complexidade desnecessária.
Como escrever uma partitura para a orquestra seguir — GitOps
Quando um maestro escreve rápido e forte na partitura, os músicos tocam de acordo sem precisar ser instruídos nota por nota. aplica a mesma ideia a clusters Kubernetes. Você declara o estado desejado do cluster como arquivos YAML em um repositório Git, e um agente compara continuamente esse estado declarado com o estado real do cluster e reconcilia quaisquer diferenças.
e são as principais ferramentas GitOps. O Flux consulta o repositório Git ou escuta webhooks para detectar mudanças e aplicá-las ao cluster. O ArgoCD adiciona uma UI de visualização e políticas de sincronização. No Azure, conecta-se o AKS ao e instala-se a extensão do Flux para gerenciar o GitOps centralmente.
O valor central do GitOps é a trilha de auditoria: cada mudança de infraestrutura é um commit no Git, registrando quem mudou o quê, quando e por quê. Reversões são feitas com . É comum combinar Azure Pipelines (build/test) com GitOps (estado do cluster), mantendo as responsabilidades separadas.
Mantendo o tráfego fluindo enquanto se repavimenta a estrada — Migrações de banco de dados
Não se fecha a estrada inteira para fazer um reparo — fecha-se uma faixa e o tráfego segue pela outra. As mudanças de esquema de banco de dados são a parte mais delicada de uma implantação: aplicativos trocam rápido, mas esquemas são difíceis de reverter.
A abordagem segue três etapas: Expand, Migrate e Contract. Primeiro se adiciona a nova coluna (Expand), depois se migram os dados existentes para ela (Migrate) e por fim se remove a coluna antiga (Contract). Durante a fase Expand, tanto o esquema antigo quanto o novo são suportados simultaneamente, de modo que em uma implantação Blue-Green o aplicativo Green pode usar o novo esquema enquanto o aplicativo Blue continua usando o antigo sem falhas.
O princípio é: nunca excluir ou renomear uma coluna existente enquanto a versão antiga do aplicativo não tiver sido desativada. No Azure, ferramentas como EF Core Migrations, DACPAC/BACPAC e Flyway automatizam essa disciplina. Cada script de migração no pipeline deve ser idempotente — executá-lo várias vezes deve produzir o mesmo resultado.
Resumo do Exame
"Enviar apenas uma porção do tráfego para a nova versão para monitoramento" -- Implantação Canary "Manter dois ambientes e mudar o tráfego atomicamente" -- Blue-Green / Slot Swap "Separar a implantação do código do lançamento de funcionalidades" -- Feature Flag "Armazenar e gerenciar Feature Flags no Azure" -- Azure App Configuration + Feature Manager "Repositório Git como fonte única de verdade para o estado do cluster" -- GitOps "Agente GitOps gerenciado para AKS no Azure" -- Azure Arc + extensão Flux "Condição obrigatória quando versões antiga e nova estão em execução simultânea no Rolling" -- Compatibilidade retroativa da API "Adicionar coluna, migrar dados, remover coluna antiga para proteger o app em execução" -- Expand-Migrate-Contract (Forward-only) "Derrubar todas as instâncias antes de implantar a nova versão, com downtime aceito" -- Implantação Recreate "Parâmetros de controle de ritmo no Rolling do AKS" -- maxUnavailable / maxSurge
Blue-Green = reversão imediata, Canary = validação gradual, Feature Flag = separar implantação do lançamento, GitOps = Git como fonte de verdade.