Publicar uma versão nova do App Service direto em produção é sempre um momento de tensão: se algo der errado, os usuários sentem na hora. Deployment Slots no App Service resolvem isso com uma técnica simples — subir a versão nova num ambiente isolado, aquecer a aplicação e só então trocar o tráfego, sem downtime e com rollback praticamente instantâneo.
Neste guia rápido você vai ver como criar um slot de staging, publicar o deploy nele, marcar configurações que não devem trocar de ambiente (as chamadas slot settings) e executar o swap com preview — a forma recomendada de trocar produção sem surpresas. Tudo via Azure CLI, sem depender de Terraform ou de portal.
Sumário
- Pré-requisitos
- Criando o slot de staging
- Publicando o deploy no slot
- Slot settings: o que não deve trocar no swap
- Swap com preview (warm-up antes de trocar)
- Rollback: desfazendo um swap
- Troubleshooting comum
- Conclusão
- Referências oficiais
Pré-requisitos
Deployment Slots no App Service só existem nos planos Standard, Premium ou Isolated — não estão disponíveis no Free, Shared nem Basic. Se o seu App Service estiver num desses planos menores, o primeiro passo é fazer o scale up:
az appservice plan update \
--name plan-meuapp \
--resource-group rg-appservice-lab \
--sku S1Criando o slot de staging
Com --configuration-source o slot novo já nasce clonado das configurações do slot de produção, evitando divergência de app settings logo de cara:
az webapp deployment slot create \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--slot staging \
--configuration-source meuapp-prod
az webapp deployment slot list \
--name meuapp-prod \
--resource-group rg-appservice-lab \
-o tableCada slot ganha sua própria URL de teste (meuapp-prod-staging.azurewebsites.net), então dá pra validar o deploy isoladamente antes de qualquer troca de tráfego.
Publicando o deploy no slot
O comando az webapp deploy é a forma unificada de publicar (zip, war, jar ou pasta), e aceita --slot pra mandar direto pro staging em vez de produção:
az webapp deploy \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--slot staging \
--src-path ./app.zip \
--type zipNesse ponto, produção continua intocada — quem visita meuapp-prod.azurewebsites.net nem percebe que existe uma versão nova esperando no staging.
Slot settings: o que não deve trocar no swap
Por padrão, o swap troca tudo — código, app settings e connection strings vão junto. Isso é um problema pra valores que precisam ficar fixos por ambiente, como a connection string do banco de staging. A solução é marcar o setting como “deployment slot setting” (sticky), com --slot-settings em vez de --settings:
az webapp config appsettings set \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--slot staging \
--slot-settings ENVIRONMENT=staging DB_CONNECTION="Server=stg-db;..."Settings marcados como slot setting ficam presos ao slot, não à versão do código — mesmo depois do swap, o slot que virou “staging” continua com ENVIRONMENT=staging. Sem isso, um swap acidentalmente aponta produção pra um banco de teste, e isso já derrubou aplicação de gente que não sabia dessa regra.
Swap com preview (warm-up antes de trocar)
Um swap direto já é rápido e sem downtime — o App Service aquece as instâncias do slot de destino antes de rotear tráfego. Mas em aplicações com inicialização pesada (cache, conexões de pool, JIT), o swap com preview (multi-phase swap) é mais seguro: ele aplica a configuração final no staging sem trocar o tráfego ainda, dando espaço pra validar antes do “vai valer”:
# Fase 1: aplica a config de produção no staging, mas mantém o tráfego como está
az webapp deployment slot swap \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--slot staging \
--target-slot production \
--action preview
# valide em meuapp-prod-staging.azurewebsites.net com a config real de produção...
# Fase 2: completa o swap (agora sim troca o tráfego)
az webapp deployment slot swap \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--slot staging \
--target-slot production \
--action swapO equivalente em PowerShell usa o cmdlet Switch-AzWebAppSlot, com o parâmetro -SwapWithPreviewAction controlando a mesma lógica de duas fases:
Switch-AzWebAppSlot -ResourceGroupName rg-appservice-lab -Name meuapp-prod `
-SourceSlotName staging -DestinationSlotName production `
-SwapWithPreviewAction ApplySlotConfig
Switch-AzWebAppSlot -ResourceGroupName rg-appservice-lab -Name meuapp-prod `
-SourceSlotName staging -DestinationSlotName production `
-SwapWithPreviewAction CompleteSlotSwapRollback: desfazendo um swap
A maior vantagem do swap é que ele não apaga nada — só troca os apontamentos. Se algo passar despercebido na validação e aparecer só depois em produção, o rollback é o mesmo comando, na direção contrária:
az webapp deployment slot swap \
--name meuapp-prod \
--resource-group rg-appservice-lab \
--slot production \
--target-slot stagingIsso volta a versão anterior pra produção em segundos — muito mais rápido que um redeploy a partir do zero.
Troubleshooting comum de Deployment Slots no App Service
Problemas mais frequentes de quem está começando com Deployment Slots no App Service:
| Sintoma | Causa | Solução |
|---|---|---|
Operation not allowed on Free/Shared/Basic tier | Plano abaixo de Standard | Scale up pra S1 ou superior antes de criar o slot |
| Connection string de staging aparece em produção após o swap | Setting não marcado como sticky | Recriar com --slot-settings em vez de --settings |
| App fica lento logo após o swap | Swap direto sem warm-up em app com boot pesado | Usar swap com preview (--action preview antes de --action swap) |
Swap operation already in progress | Um swap anterior ainda não terminou | Aguardar conclusão ou checar az webapp deployment list-publishing-profiles pra confirmar o estado |
Conclusão
Com Deployment Slots no App Service, o deploy deixa de ser um evento arriscado: você publica isolado, aquece com o swap em preview, valida com calma e só então troca o tráfego — e se precisar voltar atrás, é o mesmo comando ao contrário. Pra times que ainda fazem deploy direto em produção, esse é um dos ajustes de maior retorno com menor esforço no App Service.
Referências oficiais
- Configurar Deployment Slots no Azure App Service (Microsoft Learn)
- az webapp deployment slot — referência da CLI (Microsoft Learn)
- Switch-AzWebAppSlot (Microsoft Learn)
Interessado em saber mais sobre artigos relacionados ao Microsoft Azure CLIQUE AQUI
🚀 Vamos nos conectar?
Não perca nenhuma oportunidade! Cadastre-se nas minhas redes e no canal do YouTube para receber conteúdos de TI, Cloud, Azure, Kubernetes e DevOps em primeira mão.
Dica: No Facebook, todos os artigos do blog são publicados automaticamente. Vale a pena curtir!
💬 Dúvidas ou Problemas?
Com o intuito de ajudar a comunidade, caso você tenha dúvidas ou encontre problemas na execução dos comandos deste artigo, deixe um comentário abaixo. Responderei o mais breve possível!
Muito obrigado pela visita e até o próximo post!
Jefferson Castilho Especialista em Cloud & DevOps.Este guia técnico é exclusivo do Blog do Castilho. Explore mais conteúdos sobre Cloud e DevOps.