Cómo crear un Canary Deployment con Azure App Service y GitHub Actions

Este tutorial muestra cómo crear un Canary Deployment usando Azure App Service y GitHub Actions para enviar un porcentaje de tráfico a una nueva versión de la aplicación. Es útil para reducir riesgo, detectar regresiones y validar funcionalidades en producción con control.

Requisitos previos

• Cuenta Azure con permisos para crear App Service y Deployment Slots.
• Repositorio GitHub con el código de la aplicación (p. ej.: Node.js o .NET).
• GitHub Actions activadas en el repositorio.
• Azure CLI instalada localmente (opcional, útil para depurar).
• Conocimientos básicos de CI/CD y App Service.

Paso 1: Crear App Service y un deployment slot Canary

Crea un App Service principal (production) y un deployment slot llamado canary. El slot permite tener una versión aislada de la app sin afectar al slot de producción.

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

Paso 2: Configurar variables de entorno y conexión

Si la aplicación usa secretos o cadenas de conexión, replica solo lo necesario para el slot canary o utiliza Azure App Configuration/Key Vault. Para pruebas simples, desactiva afinidad de sesión si es necesario.

# copiar settings de production al slot canary (cuidado con secretos)
az webapp config appsettings list --name my-prod-app --resource-group myResourceGroup > settings.json
# editar settings.json y eliminar secretos sensibles
az webapp config appsettings set --name my-prod-app --resource-group myResourceGroup --slot canary --settings "@settings.json"

Paso 3: Crear GitHub Secret para deploy

Añade un secret en el repositorio GitHub para permitir que el workflow se autentique en Azure. Usa un Azure Service Principal con el mínimo de permisos (contribuidor en el Resource Group o específico para Web Apps).

# crear service principal (local)
az ad sp create-for-rbac --name github-deploy-sp --role contributor --scopes /subscriptions//resourceGroups/myResourceGroup
# outputs: appId, password, tenant
# en el repo de GitHub: Settings -> Secrets -> AZURE_CREDENTIALS = JSON con los valores arriba

Paso 4: Escribir workflow de GitHub Actions con etapa Canary

Crea un workflow que publique primero en el slot canary, ejecute pruebas de salud y luego, gradualmente, redirija el tráfico o haga swap parcial. A continuación un ejemplo simplificado que hace deploy en el slot y luego usa Azure CLI para ajustar el porcentaje de tráfico.

# .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: |
        # ejemplo 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 o por etapas extra
    - name: Promote or rollback (manual)
      run: echo "Revisar resultados y decidir swap o rollback" 

Paso 5: Automatizar escalado de tráfico y rollback

Puedes automatizar la progresión de 10% → 30% → 100% con pasos adicionales que ejecuten pruebas y recopilen métricas (latencia, errores 5xx). En caso de fallo, el workflow debe restaurar el tráfico a 0% y eliminar el slot o volver a desplegar la versión anterior.

# ejemplo de cambiar tráfico a 0% en rollback
az webapp traffic-routing set --name my-prod-app --resource-group myResourceGroup --distribution '{"canary":0}'
# opcional: swap a production si todo está OK
az webapp deployment slot swap --name my-prod-app --resource-group myResourceGroup --slot canary --target-slot production

Verificar el resultado

Confirma que el deploy canary está funcionando verificando el endpoint del slot canary y la distribución de tráfico en el portal Azure o vía CLI. Prueba el endpoint de health, analiza logs y métricas (Application Insights) y valida que el porcentaje de tráfico cambió según lo configurado.

Conclusión

Un Canary Deployment con Azure App Service y GitHub Actions reduce riesgos y permite validar versiones en producción. Próximos pasos: automatizar criterios de promoción con métricas de Application Insights, integrar circuit breakers e implementar rollback automático. Consejo: comienza con 1–5% de tráfico para generar menos impacto y prueba el rollback antes de automatizar.