Claude Code CI/CD setup: GitHub Actions से सुरक्षित PR, deploy और rollback

Claude Code से “CI/CD बना दो” कहना आसान है। YAML जल्दी मिल जाएगा। असली सवाल यह है कि वह workflow production के लिए सुरक्षित है या नहीं। अच्छा pipeline Pull Request में broken code रोकता है, fork PR को Secrets नहीं देता, staging और production अलग रखता है, production release के लिए human approval रखता है, और failure पर rollback path साफ रखता है।

इस guide में Claude Code को YAML generator नहीं, बल्कि CI/CD design partner की तरह इस्तेमाल करेंगे। CI यानी continuous integration: हर code change पर lint, type check, tests और build चलना। CD यानी continuous delivery या deployment: verified change को staging या production तक ले जाना। Gate का मतलब है अगला step चलने से पहले पास होने वाली condition। Secrets private values हैं, जैसे API key या deploy token। OIDC short-lived identity token देता है, ताकि long-lived cloud keys GitHub Secrets में न रखनी पड़ें।

Apply करने से पहले official docs देखें: Claude Code GitHub Actions, GitHub Actions workflow syntax, GITHUB_TOKEN permissions, GitHub Secrets, और GitHub Environments। नीचे के examples 2026-06-03 के हिसाब से GitHub-hosted runners, actions/checkout@v6, और actions/setup-node@v6 use करते हैं। Self-hosted runner हो तो runner version पहले check करें।

Automation boundary पहले तय करें

YAML लिखवाने से पहले तय करें कि Claude Code क्या कर सकता है और human क्या decide करेगा। Claude Code repository पढ़ सकता है, workflow बना सकता है, logs summarize कर सकता है और fixes suggest कर सकता है। लेकिन production release, token permission बढ़ाना, Secrets scope, और rollback execute करना human decision होना चाहिए।

Area	Claude Code के लिए अच्छा task	Human decision
PR checks	lint, test, typecheck, build workflow	Required checks और merge rules
PR review	risky diff, missing tests, permission issue	Change accept या reject करना
Deploy	staging/production workflow draft	Approval policy और Secrets scope
Recovery	logs summarize, rollback steps propose	production rollback चलाना

Claude Code को पहले ऐसा 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.

यह prompt agent के लिए harness बनाता है, यानी safe working frame। Team rules को CLAUDE.md में रखें; इसके लिए CLAUDE.md best practices उपयोगी है।

Use Case 1: Pull Request quality gate

पहला workflow merge से पहले broken change रोकना चाहिए। यह example lint, typecheck, test और build चलाता है, और Node.js 22/24 matrix से runtime difference पकड़ता है।

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

Typical Node project में npm test और npm run build हों तो यह copy-paste करके चल सकता है। lint और typecheck में --if-present migration के लिए है। Final CI में fake gate न रखें। Claude Code से package.json पढ़वाकर real scripts के हिसाब से workflow साफ करवाएं। Test depth के लिए testing strategies पढ़ें।

Use Case 2: Claude Code PR review को read-only रखें

Claude Code Action PR में risky workflow changes, overbroad permissions, missing tests, Secrets exposure और unrelated files पकड़ सकता है। शुरुआत में इसे comment-only रखें, auto-edit नहीं।

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

Fork guard जरूरी है: github.event.pull_request.head.repo.full_name == github.repository secret-backed workflow को external fork पर चलने से रोकता है। External PRs के लिए secret-free static checks अलग रखें और privileged workflow human approval के बाद चलाएं। pull_request_target पर खास ध्यान दें, क्योंकि यह base repository context में चलता है। Claude Code से पूछें कि कौन सा code checkout होगा और Secrets visible होंगे या नहीं। अधिक context के लिए security best practices और Git workflow देखें।

Use Case 3: staging और production deploy gates

Safe CD pattern: main push staging तक जाए, production केवल workflow_dispatch और GitHub Environment approval के बाद जाए। Production token को production Environment secret में रखें, repository-wide secret में नहीं।

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

Push पर workflow staging तक जाता है। Production manual trigger से चलेगा और Environment reviewer approval मांग सकता है। इससे merge के तुरंत बाद customer-facing incident होने का risk घटता है।

Use Case 4: rollback workflow पहले बनाएं

Rollback incident के समय design नहीं करना चाहिए। यह workflow manually दिए गए commit SHA को production में redeploy करता है।

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

Claude Code से deploy.yml और rollback workflow साथ में review करवाएं: old commit build होता है या नहीं, DB migration reversible है या नहीं, staging/production env vars अलग हैं या नहीं, और deployed SHA trace होता है या नहीं। Logs के लिए build error triage loop पढ़ें।

Common pitfalls

पहला pitfall है permissions: write-all। यह workflow pass करा सकता है, लेकिन blast radius बढ़ाता है। contents: read से शुरू करें और सिर्फ explainable permissions जोड़ें।

दूसरा pitfall है Secrets log करना। echo $DEPLOY_TOKEN न करें। Value नहीं, name और scope verify करें।

तीसरा pitfall है fake gate। --if-present migration में ठीक है, लेकिन final CI में missing script पर fail होना चाहिए।

चौथा pitfall है Claude Code को पूरा log dump देना। बेहतर input है: पहला failing command, पहली useful error line, expected behavior और local reproduction command।

Monetization और next step

CI/CD topic ClaudeCodeLab monetization के लिए अच्छा है क्योंकि reader real production risk कम करना चाहता है। Solo developer ClaudeCodeLab products से CLAUDE.md, review prompts और CI checklists ले सकता है। Team को branch protection, GitHub Actions, Secrets, approval, rollback और Claude Code review real repository में लगाना हो तो training and consultation बेहतर next step है।

आगे Advanced GitHub Actions with Claude Code, testing strategies और security best practices पढ़ें। Practical rollout में पहले PR quality gate और read-only Claude Code review लगाना production auto-deploy से ज्यादा सुरक्षित शुरुआत है। उसके बाद staging, production approval और rollback जोड़ें।