Cómo hacer despliegue continuo de una Web App en Azure App Service

Este tutorial muestra cómo configurar despliegue continuo para una Web App en Azure App Service usando GitHub Actions. Tener despliegue automático es útil para reducir errores manuales, acelerar entregas y permitir rollback sencillo cuando algo sale mal.

Requisitos previos

• Cuenta Azure con permisos para crear un Resource Group y un App Service.
• Cuenta GitHub con un repositorio que contenga una pequeña aplicación (por ejemplo, Node.js o Python).
• Azure CLI instalada y autenticada (az login) o acceso al Azure Portal.
• Noiones básicas de CI/CD y archivos YAML.

Paso 1: Crear un Resource Group y un App Service Plan

El App Service necesita un Plan que define los recursos. Aquí creamos un Resource Group y un App Service Plan en el nivel gratuito/compartido para pruebas.

# escolher nome e região
az group create --name rg-webapp-demo --location westeurope
# criar App Service Plan (SKU: B1, S1, F1, etc. - para teste usar F1 ou B1)
az appservice plan create --name plan-webapp-demo --resource-group rg-webapp-demo --sku B1 --is-linux

Paso 2: Crear una Web App

Crear la Web App que recibirá el despliegue continuo. Si tu app es Node.js, especifica la runtime; para Python, ajusta el parámetro --runtime.

# exemplo para Node.js numa app Linux
az webapp create --resource-group rg-webapp-demo --plan plan-webapp-demo --name webapp-demo-UNIQUE --runtime "NODE|18-lts"

Paso 3: Crear una Service Principal y asignar role para GitHub Actions

Para permitir que GitHub Actions despliegue en la Web App de forma segura, creamos una Service Principal y le damos la role Contributor en el recurso de la Web App (o solo en el Web Plan y en la App).

# criar service principal e capturar output em JSON
az ad sp create-for-rbac --name "gh-actions-webapp-demo" --role contributor --scopes /subscriptions//resourceGroups/rg-webapp-demo --sdk-auth

Guarda el JSON que devuelve el comando: contiene clientId, clientSecret, tenantId y subscriptionId. Lo usaremos como secret en GitHub.

Paso 4: Añadir secret en el repositorio GitHub

En GitHub, ve a Settings > Secrets & variables > Actions y crea un secret llamado AZURE_CREDENTIALS con el JSON devuelto en el paso anterior. Esto permite que la workflow se autentique en Azure.

Paso 5: Crear GitHub Actions workflow para despliegue continuo

Creamos un archivo YAML en la carpeta .github/workflows que construye y despliega la app al Azure Web App. Este ejemplo es mínimo para Node.js; adáptalo a tu stack.

name: CI-CD to Azure WebApp

on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
      - name: Install dependencies
        run: npm install
      - name: Build
        run: npm run build --if-present
      - name: 'Login to Azure'
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
      - name: 'Deploy to Azure WebApp'
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'webapp-demo-UNIQUE'
          slot-name: 'production'
          package: '.'

Paso 6: Probar y resolver errores comunes

Al hacer push a la branch main, la workflow se dispara. Errores comunes incluyen credenciales incorrectas (verifica AZURE_CREDENTIALS), nombre de la app incorrecto (verifica app-name) o runtime incompatible. Abre el log de la Action para ver mensajes de build y deploy.

Verificar el resultado

Para confirmar que el despliegue continuo funciona:

1. Haz push de un cambio simple en el repositorio (por ejemplo, modifica index.html o una ruta).
2. En GitHub Actions verifica si la workflow se ha ejecutado con éxito.
3. Abre la URL de la Web App (https://webapp-demo-UNIQUE.azurewebsites.net) y confirma el cambio.
4. Si algo falla, consulta los logs en GitHub Actions y los logs de aplicación en Azure Portal > Web App > Log Stream.

Conclusión

Ya tienes un pipeline de despliegue continuo sencillo con GitHub Actions para una Web App en Azure App Service. Siguientes pasos posibles: usar slots de deployment para pruebas A/B, configurar health checks, automatizar rollback, o añadir pruebas unitarias en la workflow. Consejo: usa un slot staging para validar deployments antes de promover a production — ¿ya has probado eso?