Claude Code CI/CD einrichten: sichere GitHub Actions für PRs, Deploys und Rollback

Claude Code kann in wenigen Minuten ein CI/CD-YAML erzeugen. Für Produktion reicht das nicht. Ein gutes Pipeline-Setup blockiert fehlerhafte Pull Requests, schützt Secrets vor Forks, trennt Staging und Production, lässt Menschen über Production entscheiden und macht Rollback planbar.

In diesem Guide ist Claude Code ein Partner für CI/CD-Design, kein YAML-Automat. CI steht für Continuous Integration: lint, type check, tests und build laufen bei jeder Änderung. CD steht für Continuous Delivery oder Deployment: geprüfte Änderungen werden in eine Umgebung gebracht. Ein gate ist eine Bedingung, die vor dem nächsten Schritt erfüllt sein muss. Secrets sind private Werte wie API keys. OIDC ermöglicht kurzlebige Identitäten, damit keine langlebigen Cloud Keys in GitHub Secrets liegen müssen.

Prüfe die offiziellen Quellen: Claude Code GitHub Actions, GitHub Actions workflow syntax, GITHUB_TOKEN permissions, GitHub Secrets und GitHub Environments. Die Beispiele verwenden GitHub-hosted runners und am 3. Juni 2026 actions/checkout@v6 sowie actions/setup-node@v6. Bei self-hosted runners zuerst die runner-Version prüfen.

Automatisierungsgrenze festlegen

Bevor du YAML schreiben lässt, muss klar sein, was Claude Code automatisieren darf. Claude Code kann das Repository lesen, Workflows vorschlagen, Logs zusammenfassen und Fixes entwerfen. Es sollte nicht selbst Token-Rechte erweitern, Production freigeben, Secrets ausgeben oder untrusted PR-Code mit privilegierten Events ausführen.

Bereich	Gute Aufgabe für Claude Code	Menschliche Entscheidung
PR checks	lint, test, typecheck, build erstellen	Required checks und Merge-Regeln
PR review	Risiken, Permissions, fehlende Tests finden	Patch annehmen oder ablehnen
Deploy	Staging/Production Workflow entwerfen	Approval und Secret-Scope
Recovery	Logs einordnen, Rollback vorschlagen	Production rollback auslösen

Nutze zuerst einen eingeschränkten Prompt:

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.

Der Prompt bildet ein harness, also einen sicheren Arbeitsrahmen für den Agenten. Dauerhafte Projektregeln gehören in CLAUDE.md; die CLAUDE.md best practices helfen beim sauberen Aufbau.

Use Case 1: Pull-Request-Quality-Gate

Der erste Workflow sollte fehlerhafte Änderungen vor dem Merge stoppen. Dieses Beispiel führt lint, typecheck, tests und build aus und prüft Node.js 22 und 24 per matrix.

# .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

Für ein typisches Node-Projekt mit npm test und npm run build ist das direkt ausführbar. lint und typecheck nutzen --if-present, damit die Einführung nicht an fehlenden scripts scheitert. Später sollte Claude Code package.json lesen und nur echte Gates übrig lassen. Testtiefe behandelst du mit testing strategies.

Use Case 2: Claude Code PR Review im Lesemodus

Claude Code Action kann Pull Requests auf riskante Workflow-Änderungen, Secrets, fehlende Tests und zu breite Berechtigungen prüfen. Starte mit Kommentaren, nicht mit automatischen Änderungen.

# .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

Die Fork-Bedingung verhindert, dass ein secret-gestützter Workflow auf externen Forks läuft. Für externe Beiträge trenne secret-freie statische Checks von einem privilegierten Workflow, der erst nach menschlicher Freigabe läuft. pull_request_target ist besonders riskant, weil es im Kontext des Basis-Repositories läuft. Wenn Claude Code es vorschlägt, muss es erklären, welcher Code ausgecheckt wird und ob Secrets sichtbar sind. Lies dazu security best practices und Git workflow.

Use Case 3: Deploy-Gates für Staging und Production

Ein pragmatischer Start: main geht automatisch nach staging, production nur über workflow_dispatch und GitHub Environment approval. Production Secrets gehören in das production Environment.

# .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

Ein push erreicht staging. Production läuft nur manuell und kann durch Environment Reviewer gestoppt werden. So verhinderst du, dass jeder Merge sofort Kunden betrifft.

Use Case 4: Rollback zuerst bauen

Rollback darf nicht erst im Incident entstehen. Dieser Workflow deployt einen angegebenen Commit SHA erneut und nutzt das production Environment.

# .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

Lass Claude Code deploy.yml und rollback-production.yml gemeinsam prüfen: baut ein alter Commit noch, sind migrations reversibel, unterscheiden sich Staging und Production bei Variablen, und ist der aktuell deployte SHA auffindbar? Für Logs passt der build error triage loop.

Typische Fallen

Erstens: permissions: write-all. Es löst kurzfristig Probleme, vergrößert aber den Schaden. Starte mit contents: read und ergänze nur begründete Rechte.

Zweitens: Secrets im Log. Kein echo $DEPLOY_TOKEN. Prüfe Namen und Scope, nie den Wert.

Drittens: falsche Gates. --if-present ist gut für Migration, aber die finale CI muss bei fehlenden Pflichtscripts fehlschlagen.

Viertens: riesige Logs an Claude Code geben. Besser sind erster fehlgeschlagener Befehl, erste relevante Fehlermeldung, erwartetes Verhalten und lokaler Repro-Befehl.

Monetarisierung und nächste Schritte

CI/CD eignet sich gut für ClaudeCodeLab, weil Leser echte Produktionsrisiken reduzieren wollen. Einzelne Entwickler starten mit ClaudeCodeLab products für CLAUDE.md, Review-Prompts und CI-Checklists. Teams, die branch protection, GitHub Actions, Secrets, approvals, rollback und Claude Code review an einem echten Repository einführen wollen, sollten training and consultation nutzen.

Als Nächstes passen Advanced GitHub Actions with Claude Code, testing strategies und security best practices. In der Praxis ist der beste erste Schritt nicht vollautomatisches Production Deployment, sondern PR Quality Gate plus read-only Claude Code Review. Danach folgen Staging, Production Approval und Rollback.