CI/CD com Claude Code: GitHub Actions seguro para PR, deploy e rollback

Pedir ao Claude Code para “criar CI/CD” gera YAML rapidamente. O ponto crítico é saber se esse YAML é seguro para produção. Um pipeline bom bloqueia Pull Requests quebrados, não expõe Secrets para forks, separa staging de production, mantém aprovação humana antes do release e oferece rollback claro.

Neste guia, Claude Code é parceiro de desenho do CI/CD, não uma fábrica de templates. CI é integração contínua: lint, type check, testes e build rodam quando o código muda. CD é entrega ou deploy contínuo: uma mudança validada segue para um ambiente. Gate é a condição que precisa passar antes do próximo job. Secrets são valores privados, como API keys. OIDC permite credenciais temporárias e evita guardar chaves cloud longas no GitHub.

Use as fontes oficiais como base: Claude Code GitHub Actions, GitHub Actions workflow syntax, GITHUB_TOKEN permissions, GitHub Secrets e GitHub Environments. Os exemplos usam GitHub-hosted runners e, em 2026-06-03, actions/checkout@v6 e actions/setup-node@v6. Com self-hosted runners, confirme a versão antes.

Defina a fronteira da automação

Antes do YAML, defina o que Claude Code pode automatizar e o que continua sendo decisão humana. Claude Code pode ler o repositório, propor workflows, resumir logs e sugerir correções. Ele não deve ampliar permissões sozinho, decidir produção, imprimir Secrets nem executar código não confiável com eventos privilegiados.

Área	Bom uso de Claude Code	Decisão humana
PR checks	Criar lint, test, typecheck e build	Checks obrigatórios e regra de merge
PR review	Apontar risco, permissões e testes faltantes	Aceitar ou rejeitar mudança
Deploy	Rascunho de staging e production	Aprovação e escopo dos Secrets
Recovery	Resumir logs e propor rollback	Executar rollback em production

Comece com um prompt restrito:

Design CI/CD for this repository.
The goals are pull request quality gates, staging deployment, Claude Code review, and production rollback.

Constraints:
- Use least-privilege GITHUB_TOKEN permissions per job.
- Do not use secrets on forked pull requests.
- If pull_request_target is suggested, explain why PR head code is not checked out.
- Put production deployment behind a GitHub Environment approval.
- Never print ANTHROPIC_API_KEY, DEPLOY_TOKEN, or other secret values.
- Produce workflow YAML that can be placed under .github/workflows/.

End with failure cases, verification commands, and rollback steps.

Esse prompt cria um harness, um quadro seguro de trabalho para o agente. Regras duradouras devem ir para CLAUDE.md; veja CLAUDE.md best practices para manter isso prático.

Caso 1: gate de qualidade no Pull Request

O primeiro workflow deve impedir merge sem validação. Este exemplo executa lint, typecheck, test e build, com matrix em Node.js 22 e 24.

# .github/workflows/ci.yml
name: ci

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    name: test-node-${{ matrix.node-version }}
    runs-on: ubuntu-latest
    timeout-minutes: 15
    strategy:
      fail-fast: false
      matrix:
        node-version: [22, 24]
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v6
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm

      - run: npm ci
      - run: npm run lint --if-present
      - run: npm run typecheck --if-present
      - run: npm test -- --runInBand

  build:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    needs: test
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm

      - run: npm ci
      - run: npm run build

Em um projeto Node típico com npm test e npm run build, isso roda direto. lint e typecheck usam --if-present para facilitar a migração inicial. Depois, peça ao Claude Code para ler package.json e remover gates falsos. Para profundidade de teste, leia testing strategies.

Caso 2: Claude Code PR review em modo leitura

Claude Code Action pode comentar riscos de PR: permissões amplas, Secrets expostos, testes ausentes, rollback frágil e mudanças fora do escopo. A primeira versão deve comentar, não editar.

# .github/workflows/claude-pr-review.yml
name: claude-pr-review

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

permissions:
  contents: read
  pull-requests: write
  issues: write

concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    if: >
      github.event.pull_request.draft == false &&
      github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v6
        with:
          persist-credentials: false

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          github_token: ${{ secrets.GITHUB_TOKEN }}
          prompt: |
            Review this pull request as a CI/CD safety reviewer.
            Focus on GitHub Actions permissions, secrets exposure, test coverage,
            deployment gates, rollback risk, and unrelated file changes.
            Do not edit files. Leave concise review comments with evidence.
          claude_args: |
            --max-turns 4

A condição de fork evita rodar um workflow com Secrets em PRs externos. Para contribuições externas, separe checks estáticos sem segredo de um workflow privilegiado que só roda após aprovação humana. Tenha cuidado com pull_request_target, porque ele roda no contexto do repositório base. Se Claude Code sugerir isso, peça justificativa. Para o checklist completo, use security best practices e Git workflow.

Caso 3: gates de deploy para staging e production

Um começo seguro é mandar main para staging automaticamente e deixar production atrás de workflow_dispatch e GitHub Environment approval. Secrets de production devem ficar no Environment production.

# .github/workflows/deploy.yml
name: deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  deployments: write

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: false

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run build

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    timeout-minutes: 10
    environment: staging
    env:
      APP_ENV: staging
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run deploy:staging

  deploy-production:
    if: github.event_name == 'workflow_dispatch'
    needs: deploy-staging
    runs-on: ubuntu-latest
    timeout-minutes: 10
    environment: production
    env:
      APP_ENV: production
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run deploy:production

No push, o workflow chega a staging. Production só roda manualmente e pode exigir reviewer no Environment. Isso evita o erro comum de publicar em produção no mesmo instante do merge.

Caso 4: rollback antes da crise

Rollback precisa existir antes do incidente. Este workflow redeploya um commit SHA escolhido manualmente, com approval de production.

# .github/workflows/rollback-production.yml
name: rollback-production

on:
  workflow_dispatch:
    inputs:
      target_sha:
        description: "Commit SHA to redeploy to production"
        required: true
        type: string

permissions:
  contents: read
  deployments: write

jobs:
  rollback:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    environment: production
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ inputs.target_sha }}

      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm

      - run: npm ci
      - run: npm run build
      - run: npm run deploy:production

Peça para Claude Code revisar deploy.yml e rollback-production.yml juntos: commit antigo ainda builda, migrations são reversíveis, variáveis diferem entre staging e production, e o SHA atualmente implantado é rastreável? Para logs, use o build error triage loop.

Armadilhas comuns

Primeira: permissions: write-all. Pode resolver rápido, mas aumenta o raio do dano. Comece com contents: read e adicione só o necessário.

Segunda: imprimir Secrets. Não use echo $DEPLOY_TOKEN. Verifique nome e escopo, nunca valor.

Terceira: gate falso. --if-present ajuda na migração, mas o gate final deve falhar se um script obrigatório não existir.

Quarta: despejar logs enormes no Claude Code. Melhor passar o primeiro comando que falhou, a primeira linha útil, o esperado e o comando local de reprodução.

Monetização e próximos passos

CI/CD funciona bem para monetização porque o leitor tem risco real de produção. Desenvolvedores solo podem começar com ClaudeCodeLab products para CLAUDE.md, prompts de review e checklists. Times que precisam aplicar branch protection, GitHub Actions, Secrets, approvals, rollback e Claude Code review em um repositório real devem usar training and consultation.

Continue com Advanced GitHub Actions with Claude Code, testing strategies e security best practices. Na prática, o melhor primeiro passo é PR quality gate mais Claude Code review em modo leitura. Depois vêm staging, approval de production e rollback.