DevOpsQuest
0 XP
Módulo 5 · CI/CD com GitHub Actions

Deploy, rollback e depuração de pipeline quebrado

Avançado 45 min+25 XPGitHub ActionsDockeract

Objetivos desta aula

  • Estruturar deploy com aprovação
  • Executar rollback em minutos
  • Depurar workflow com método

Deploy sem rollback planejado é aposta. O padrão mínimo é: artefato imutável, versão anterior conhecida e um caminho de volta testado — seja um job manual que reimplanta a versão anterior, seja rollout undo no Kubernetes. Rollback precisa ser tão rotineiro que ninguém hesite em usá-lo às três da manhã.

Para depurar pipeline, siga a ordem: leia o primeiro erro do log (não o último), reproduza o comando localmente com as mesmas versões, verifique diferenças de ambiente (variáveis, permissões, cache) e só então mexa no YAML. Ative debug detalhado quando necessário e use act para iterar localmente sem poluir o histórico de execuções.

Três causas cobrem a maioria dos casos: variável ou secret ausente no contexto (PR de fork não recebe secrets), permissão insuficiente do token e diferença de versão entre a máquina local e o runner.

1. Estratégias de deploy

  • Rolling: troca instâncias aos poucos (padrão do Kubernetes)
  • Blue/green: sobe o ambiente novo completo e vira o tráfego de uma vez
  • Canary: manda 5% do tráfego para a versão nova e aumenta se as métricas ficarem boas

2. Aprovação e environments

No GitHub, o environment production pode exigir revisores e só aceitar deploy da main. Isso dá controle sem burocracia.

3. Rollback rápido

Com tags imutáveis, rollback é redeploy da versão anterior: kubectl rollout undo ou reverter o commit no repositório GitOps. Treine antes de precisar.

4. Smoke test pós-deploy

Depois do deploy, o pipeline chama o /health e uma rota crítica; se falhar, faz rollback automático.

5. Depurando pipeline quebrado

  1. Leia o primeiro erro, não o último.
  2. Reproduza localmente com o mesmo comando.
  3. Ative logs de debug (ACTIONS_STEP_DEBUG).
  4. Verifique o que mudou: dependência, action, runner, secret expirado.

6. Checagem final

Você deve fazer deploy com aprovação, validar com smoke test e reverter em menos de 5 minutos.

Na prática

Deploy com rollback manual

yaml

name: deploy-e-rollback

on:
  workflow_dispatch:
    inputs:
      versao:
        description: "Tag da imagem a implantar (ex.: v1.2.0)"
        required: true
      acao:
        type: choice
        options: [deploy, rollback]
        default: deploy

jobs:
  aplicar:
    runs-on: ubuntu-latest
    environment: producao
    steps:
      - uses: actions/checkout@v4
      - name: Registrar versao atual
        run: echo "ANTERIOR=$(cat .deploy/current-version)" >> "$GITHUB_ENV"
      - name: Aplicar
        run: |
          set -euo pipefail
          ALVO="${{ inputs.versao }}"
          echo "aplicando $ALVO (anterior: $ANTERIOR)"
          ./scripts/deploy.sh "$ALVO"
      - name: Verificar saude
        run: ./scripts/health-check.sh https://api.cloudshop.dev/health
      - name: Rollback automatico se falhar
        if: failure()
        run: ./scripts/deploy.sh "$ANTERIOR"

Depurar localmente

bash

gh run list --limit 5
gh run view --log-failed
gh run rerun <run-id> --failed

# reproduzir o job localmente
act pull_request -j qualidade --container-architecture linux/amd64

# habilitar log detalhado (variaveis de repositorio)
gh variable set ACTIONS_STEP_DEBUG --body true

Deploy com smoke test e rollback automático

yaml

deploy:
  needs: build
  environment: production        # exige aprovacao configurada no repositorio
  runs-on: ubuntu-latest
  steps:
    - run: kubectl set image deploy/api api=ghcr.io/cloudshop-org/cloudshop-api:sha-${{ github.sha }}
    - run: kubectl rollout status deploy/api --timeout=180s
    - name: smoke test
      run: curl -fsS --retry 5 --retry-delay 5 https://api.cloudshop.dev/health
    - name: rollback
      if: failure()
      run: kubectl rollout undo deploy/api

Por que isso importa

Métricas DORA valorizam tempo de restauração. Rollback rápido é a resposta prática.

Erro comum

Tentar corrigir para frente sob pressão em vez de reverter e investigar com calma.

Dica de produção

Verificação de saúde pós-deploy com rollback automático em falha é o padrão que evita madrugadas.

Alerta de segurança

PRs de forks não recebem secrets: pipelines que dependem disso falham e tentam contornos inseguros.

Pergunta de entrevista

Descreva seu processo para depurar um workflow que falha só no runner.

Glossário

act
Ferramenta que executa workflows do GitHub Actions localmente em containers.
MTTR
Tempo médio de restauração do serviço após um incidente.
canary
Liberação gradual para uma fração do tráfego antes do total.
blue/green
Dois ambientes completos com troca de tráfego instantânea.
smoke test
Teste rápido que confirma que o essencial funciona após o deploy.

Conexão com o CloudShop

Criar o workflow de rollback do CloudShop e testá-lo com a versão anterior.

Quiz da aula

  1. 1. Deploy quebrou produção. Primeira ação correta?

  2. 2. Qual estratégia expõe a versão nova a só uma parte dos usuários?

  3. 3. Ao depurar um pipeline, qual erro ler primeiro?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima