APRENDER. PRATICAR. EVOLUIR.1. Preparar a configuração que realmente vai executar
Num portal fictício de operações, a versão nova funciona em staging mas falha depois da promoção. A equipa testou código e dados de teste, sem verificar a identidade e as dependências da configuração de produção. Em App Service, nem tudo acompanha o conteúdo durante um swap: managed identities e integração VNet permanecem associadas ao slot. Algumas definições da aplicação e connection strings podem ser marcadas como específicas do slot. Mantém uma matriz curta com componente, comportamento esperado, owner e evidência de acesso. O ensaio deve cobrir a combinação final e a fase de preparação. Uma ligação bem-sucedida com uma conta administrativa de desenvolvimento não demonstra que a identidade usada em produção conseguirá ler o segredo ou executar a operação necessária.
2. Aquecer e avaliar prontidão sem efeitos de negócio
O endpoint de warm-up deve preparar a aplicação sem gerar instruções financeiras, emails reais ou jobs duplicados. No exemplo fictício, a página inicial responde mesmo quando a ligação à base está indisponível. Aceitar essa resposta deixa a versão nova avançar sem provar a dependência crítica. Define critérios explícitos para o percurso de readiness e confirma a configuração de warm-up, em vez de inferir prontidão a partir de qualquer resposta HTTP. Health Check também exige um percurso com semântica adequada: respostas 2xx indicam saúde; redirects para login não equivalem a sucesso. Não faças uma dependência opcional retirar todas as instâncias se o serviço principal ainda pode funcionar. Separa saúde mínima, funcionalidades degradadas e autorização de promoção, com sinais que a equipa consegue explicar.
3. Desenhar entrada, saída e resolução de nomes
Desenha os dois sentidos do tráfego separadamente. O private endpoint permite entrada privada; a integração VNet serve percursos de saída. A aplicação fictícia precisa de receber pedidos de uma rede interna e consultar uma base por endereço privado. Demonstrar apenas a entrada não prova o segundo percurso. Regista o nome usado pelo cliente, a resolução esperada, a rota e a autorização em cada dependência. Se o requisito exclui acesso público, configura e verifica essa restrição explicitamente. Para deployments privados, o agente de CI/CD também precisa de alcançar o endpoint adequado; a resolução do nome da aplicação não substitui a resolução de SCM. Um teste feito no portátil de um administrador pode usar DNS e rotas diferentes dos usados pelo agente ou pela aplicação.
4. Limitar exposição e definir quando parar
Uma promoção progressiva precisa de um critério de observação, não apenas de uma percentagem de tráfego. Para o portal fictício, acompanha erros técnicos, conclusão de instruções e latência de uma operação representativa. Define a amostra e a duração necessárias antes de aumentar exposição. Poucas chamadas sem erros não demonstram capacidade para o pico de fecho diário. A equipa deve saber quem pode interromper a mudança e qual a ação seguinte quando uma métrica ultrapassa o limite acordado. A decisão deve considerar o impacto de parar, incluindo trabalho já aceite e consumidores que receberam o novo contrato. Regista também falhas de telemetria: falta de dados não deve autorizar automaticamente a próxima etapa. Estes critérios pertencem ao plano da mudança e ao handover para RUN.
5. Manter compatibilidade durante a janela de regresso
Trocar código não desfaz automaticamente alterações numa base de dados externa. No caso fictício, a versão nova elimina uma coluna que a anterior ainda lê. Voltar ao código anterior deixa o serviço igualmente incapaz de funcionar. Planeia uma evolução compatível: acrescentar a nova estrutura, preparar leituras e escritas, migrar dados com controlo e retirar a estrutura antiga apenas depois da janela de regresso acordada. Testa ambas as versões com o estado previsto nessa janela. Se houver necessidade de restaurar dados, avalia as instruções válidas recebidas entretanto e como serão reconciliadas. Um procedimento que recupera disponibilidade mas perde trabalho aceite pode falhar o requisito de negócio. O modelo local abaixo mostra apenas o movimento de campos escolhido para um exercício; não simula o algoritmo completo de swap do Azure.
6. Separar mudança de versão de recuperação regional
Slots de uma aplicação não são uma segunda região de recuperação. Para um requisito de indisponibilidade regional, identifica outra implantação, dados recuperáveis, entrada de tráfego e todas as dependências necessárias. Um diagrama com duas aplicações continua incompleto se ambas dependem de um único segredo, endpoint ou processo manual inacessível no incidente. No projeto fictício, RUN aceita a transição apenas depois de ver uma operação funcional no destino e um procedimento de regresso coerente com os dados. Regista capacidade disponível, tempo medido, decisões de reconciliação e responsabilidades. A redundância zonal trata outro âmbito de falha e deve ser avaliada separadamente. A entrega final inclui evidência de deployment, recuperação e operação diária; a existência de uma segunda cópia de código não demonstra por si só nenhum desses resultados.
from copy import deepcopy
def exercise_swap(left, right):
# Selected steady-state fields only; not an Azure swap implementation.
a, b = deepcopy(left), deepcopy(right)
a["code"], b["code"] = b["code"], a["code"]
return a, b
production = {"code": "v1", "identity": "prod-id", "sticky_db": "prod-db"}
staging = {"code": "v2", "identity": "stage-id", "sticky_db": "stage-db"}
after_prod, after_stage = exercise_swap(production, staging)
assert after_prod["code"] == "v2"
assert after_stage["code"] == "v1"
assert after_prod["identity"] == "prod-id"
assert after_prod["sticky_db"] == "prod-db"
assert production["code"] == "v1" # inputs preserved
assert exercise_swap(after_prod, after_stage) == (production, staging)
print("six selected-field checks passed; no Azure swap or database rollback performed")
Caso fictício: staging passa os testes, mas a identidade de produção não tem acesso ao segredo. O responsável interrompe a promoção, valida o acesso necessário e repete o ensaio sem alargar permissões indiscriminadamente.
Armadilhas comuns
Assumir que identidade acompanha código; usar um endpoint com efeitos de negócio como warm-up; confundir entrada privada com saída; prometer reversão de dados por swap.
Tópicos relacionados: CI/CD e critérios de promoção · Compatibilidade de dados · Recuperação regional
Uma mudança segura depende da combinação de código, configuração, identidade, rede e dados que irá realmente executar.
Referência: Set up staging environments in App Service · AZ-305 objectives 2026-04-17