Como criar um Canary Deployment com Azure App Service e GitHub Actions

Este tutorial mostra como criar um Canary Deployment usando Azure App Service e GitHub Actions para enviar uma percentagem de tráfego para uma versão nova da aplicação. É útil para reduzir risco, detetar regressões e validar funcionalidades em produção com controlo.

Pré-requisitos

• Conta Azure com permissões para criar App Service e Deployment Slots.
• Repositório GitHub com o código da aplicação (ex.: Node.js ou .NET).
• GitHub Actions ativadas no repositório.
• Azure CLI instalada localmente (opcional, útil para depurar).
• Conhecimentos básicos de CI/CD e App Service.

Passo 1: Criar App Service e um deployment slot Canary

Cria um App Service principal (production) e um deployment slot chamado canary. O slot permite ter uma versão isolada da app sem afectar o slot de produção.

az group create --name myResourceGroup --location northeurope
az appservice plan create --name myPlan --resource-group myResourceGroup --sku S1
az webapp create --resource-group myResourceGroup --plan myPlan --name my-prod-app
az webapp deployment slot create --name my-prod-app --resource-group myResourceGroup --slot canary

Passo 2: Configurar variáveis de ambiente e ligação

Se a aplicação usa segredos ou strings de ligação, replica apenas o necessário para o slot canary ou utilize Azure App Configuration/Key Vault. Para testes simples, desactivar afinidade de sessão se necessário.

# copiar settings do production para o slot canary (cuidado com segredos)
az webapp config appsettings list --name my-prod-app --resource-group myResourceGroup > settings.json
# editar settings.json e remover segredos sensíveis
az webapp config appsettings set --name my-prod-app --resource-group myResourceGroup --slot canary --settings "@settings.json"

Passo 3: Criar GitHub Secret para deploy

Adiciona um secret no repositório GitHub para permitir que o workflow autentique no Azure. Usa um Azure Service Principal com o mínimo de permissões (contribuidor no Resource Group ou específico para Web Apps).

# criar service principal (local)
az ad sp create-for-rbac --name github-deploy-sp --role contributor --scopes /subscriptions//resourceGroups/myResourceGroup
# outputs: appId, password, tenant
# no GitHub repo: Settings -> Secrets -> AZURE_CREDENTIALS = JSON com os valores acima

Passo 4: Escrever workflow de GitHub Actions com etapa Canary

Cria um workflow que publica primeiro no slot canary, executa testes de saúde e depois, gradualmente, reencaminha o tráfego ou faz swap parcial. Abaixo um exemplo simplificado que faz deploy no slot e depois usa Azure CLI para ajustar a percentagem de tráfego.

# .github/workflows/canary-deploy.yml
name: Canary Deploy
on:
  push:
    branches: [ main ]

jobs:
  deploy-canary:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Login to Azure
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    - name: Build
      run: |
        # exemplo Node.js
        npm install
        npm run build
    - name: Deploy to canary slot
      uses: azure/webapps-deploy@v2
      with:
        app-name: my-prod-app
        slot-name: canary
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        package: .
    - name: Run smoke tests against canary
      run: |
        # simples healthcheck
        curl -fsS https://my-prod-app-canary.azurewebsites.net/health || exit 1
    - name: Shift 10% traffic to canary
      run: |
        az webapp traffic-routing set --name my-prod-app --resource-group myResourceGroup --distribution '{"canary":10}'
        # monitorizado por tooling externo ou por etapas extra
    - name: Promote or rollback (manual)
      run: echo "Rever resultados e decidir swap ou rollback" 

Passo 5: Automatizar escalonamento de tráfego e rollback

Podes automatizar a progressão de 10% → 30% → 100% com passos adicionais que executam testes e recolhem métricas (latência, erros 5xx). Em caso de falha, o workflow deve restaurar o tráfego para 0% e remover o slot ou fazer redeploy da versão anterior.

# exemplo de alterar tráfego para 0% em rollback
az webapp traffic-routing set --name my-prod-app --resource-group myResourceGroup --distribution '{"canary":0}'
# opcional: swap para production se tudo estiver OK
az webapp deployment slot swap --name my-prod-app --resource-group myResourceGroup --slot canary --target-slot production

Verificar o resultado

Confirmar que o deploy canary está a funcionar verificando o endpoint do slot canary e a distribuição de tráfego no portal Azure ou via CLI. Testa o endpoint de health, analisa logs e métricas (Application Insights) e valida que a percentagem de tráfego mudou conforme configurado.

Conclusão

Um Canary Deployment com Azure App Service e GitHub Actions reduz riscos e permite validar versões em produção. Próximos passos: automatizar critérios de promoção com métricas do Application Insights, integrar circuit breakers e implementar rollback automático. Dica: começa com 1–5% de tráfego para produzir menos impacto e testa o rollback antes de automatizar.