Como fazer deploy contínuo de uma Web App no Azure App Service

Este tutorial mostra como configurar deploy contínuo para uma Web App no Azure App Service usando GitHub Actions. Ter deploy automático é útil para reduzir erros manuais, acelerar entregas e permitir rollback simples quando algo corre mal.

Pré-requisitos

• Conta Azure com permissões para criar um Resource Group e um App Service.
• Conta GitHub com um repositório contendo uma pequena aplicação (por exemplo, Node.js ou Python).
• Azure CLI instalada e autenticada (az login) ou acesso ao Azure Portal.
• Noções básicas de CI/CD e ficheiros YAML.

Passo 1: Criar um Resource Group e um App Service Plan

O App Service precisa de um Plan que define os recursos. Aqui criamos um Resource Group e um App Service Plan no nível gratuito/partilhado para testes.

# 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

Passo 2: Criar uma Web App

Criar a Web App que receberá o deploy contínuo. Se a tua app for Node.js, especifica a runtime; para Python, ajusta o 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"

Passo 3: Criar uma Service Principal e atribuir role para GitHub Actions

Para permitir que o GitHub Actions faça deploy na Web App de forma segura, criamos uma Service Principal e damos-lhe a role Contributor no recurso da Web App (ou apenas no Web Plan e na 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 o JSON que o comando devolve: contém clientId, clientSecret, tenantId e subscriptionId. Vamos usá-lo como secret no GitHub.

Passo 4: Adicionar secret no repositório GitHub

No GitHub, vai a Settings > Secrets & variables > Actions e cria um secret chamado AZURE_CREDENTIALS com o JSON retornado no passo anterior. Isto permite que a workflow se autentique no Azure.

Passo 5: Criar GitHub Actions workflow para deploy contínuo

Criamos um ficheiro YAML na pasta .github/workflows que constrói e faz deploy da app para o Azure Web App. Este exemplo é mínimo para Node.js; adapta ao teu 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: '.'

Passo 6: Testar e resolver erros comuns

Ao fazer push para a branch main, a workflow é disparada. Erros comuns incluem credenciais incorretas (verifica AZURE_CREDENTIALS), nome da app errado (verifica app-name) ou runtime incompatível. Abre o log da Action para ver mensagens de build e deploy.

Verificar o resultado

Para confirmar que o deploy contínuo funciona:

1. Faz push de uma alteração simples no repositório (por exemplo, altera index.html ou route).
2. No GitHub Actions verifica se a workflow correu com sucesso.
3. Abre a URL da Web App (https://webapp-demo-UNIQUE.azurewebsites.net) e confirma a alteração.
4. Se algo falhar, vê os logs no GitHub Actions e os logs de aplicação no Azure Portal > Web App > Log Stream.

Conclusão

Já tens um pipeline de deploy contínuo simples com GitHub Actions para uma Web App no Azure App Service. Próximos passos possíveis: usar slots de deployment para testes A/B, configurar health checks, automatizar rollback, ou adicionar testes unitários na workflow. Dica: usa um slot staging para validar deployments antes de promover para production — já experimentaste isso?