Conceito e mecanismo
App Service slots permitem preparar uma aplicação e trocar conteúdo e certas configurações com produção. Contudo, nem tudo acompanha o código. Managed identities permanecem no slot; app settings e connection strings podem ser configuradas para ficar específicas do slot. Antes da mudança, confirma identidade runtime, permissões e configuração efetiva no destino. Uma aplicação que acede a Key Vault em staging pode falhar em produção se a identidade de destino não tiver o acesso necessário. O warm-up também precisa de interpretação: no comportamento predefinido descrito, qualquer resposta HTTP pode contar como aquecimento. Isso não prova que um pedido de negócio termina corretamente ou que as dependências estão disponíveis.
Aplicação guiada
Define validação representativa, limites de erro e sinais para parar a exposição progressiva. Se um canary excede o limite acordado, o sucesso anterior do build não autoriza expandir. Uma feature flag pode desligar uma função, mas não desfaz ficheiros já enviados a um parceiro. O plano de recuperação precisa de reconciliação e tratamento de efeitos externos. O mesmo acontece com schema: trocar o binário anterior não recupera uma coluna removida de que esse binário depende. Planeia compatibilidade entre versões e fases de dados, incluindo como recuperar ou avançar com segurança. No comité, distingue rollback de código, recuperação de dados e conclusão da operação de negócio. A decisão deve usar evidência do serviço, não apenas o estado verde do deployment.
Desligar a flag impede novos envios, mas três ficheiros duplicados já chegaram ao parceiro. A recuperação inclui reconciliação.
Armadilhas comuns
Identidade a acompanhar código; HTTP como sucesso funcional; flag como undo; rollback sem schema compatível.
Tópicos relacionados: IaC, fiabilidade e tempo total · Identidade, segredos e dependências do pipeline
Planeia recuperação para os efeitos produzidos, não apenas para o binário.
Referência: App Service deployment slots · AZ-400 objectives 2026-07-27