CD Pipeline Generator

CD is CI plus consequences. The artifact from CI flows through environments with gates between them. The shape is always the same; only the deploy mechanism changes.

The promotion ladder

CI artifact ──▶ dev ──▶ staging ──[gate]──▶ prod

Each arrow is a deploy. Each [gate] is a decision point. The pipeline's job is to make the arrows automatic and the gates explicit.

Step 1 — Determine the deploy mechanism

Read the repo. A Dockerfile + k8s/ dir means Kubernetes. A serverless.yml means serverless. A Procfile means PaaS.

Step 2 — One artifact, many environments

The artifact is built once (in CI) and promoted unchanged. If you rebuild per environment, your staging test means nothing about prod.

• Containers: tag with git SHA. staging deploys :abc123; prod deploys the same :abc123 after staging passes.
• Packages: build once, stash in an artifact store, download per environment.

Environment-specific config comes from the environment, not from the artifact. Env vars, mounted configs, secret stores.

Step 3 — Gates

Start simple. Human approval before prod, smoke test after every deploy. Add soak/canary only when there's evidence they're needed.

Worked example

Repo: Node app, Dockerfile, k8s/deployment.yaml, deploys to GKE.

# .github/workflows/cd.yml
name: CD

on:
  workflow_run:
    workflows: [CI]
    types: [completed]
    branches: [main]

jobs:
  deploy-staging:
    if: github.event.workflow_run.conclusion == 'success'
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - run: |
          gcloud auth configure-docker
          kubectl set image deployment/app app=gcr.io/proj/app:${{ github.sha }} -n staging
      - run: ./scripts/smoke-test.sh https://staging.example.com

  deploy-prod:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production   # ← GitHub env protection = human approval gate
    steps:
      - uses: actions/checkout@v4
      - run: |
          gcloud auth configure-docker
          kubectl set image deployment/app app=gcr.io/proj/app:${{ github.sha }} -n prod
      - run: ./scripts/smoke-test.sh https://example.com

Same SHA both times. The approval gate lives in GitHub's environment protection rules — not in the YAML.

Edge cases

• No staging environment exists: Don't invent one in YAML. Either the user sets one up, or you generate a prod-only pipeline with a louder approval gate. Flag the gap.
• Database migrations: They can't be rolled back by redeploying the old image. Put migration in a separate gated job. → rollback-strategy-advisor.
• Multiple services, one repo: Deploy jobs per service, with paths: triggers so touching service A doesn't redeploy service B.
• The smoke test can't run from the CI runner (private network): Run it from inside the cluster as a Job, and have the pipeline poll its result.

Do not

• Do not rebuild the artifact per environment. Build once in CI, promote the immutable artifact.
• Do not put the approval logic in a if: github.actor == 'alice' condition. Use platform environment protection — it's auditable.
• Do not || true a failing smoke test. A smoke test that can't block is theater.
• Do not store deploy credentials as plaintext env vars. Reference ${{ secrets.* }} and list what must be configured.
• Do not generate a canary/blue-green pipeline for a system that gets 10 requests a day. Match sophistication to traffic.

Output format

## Promotion ladder
<env> → <env> → [gate] → <env>

## Deploy mechanism
<detected target + command>

## Pipeline
<file path>
<code block>

## Required configuration
- Secrets: <list>
- Environment protection rules: <which envs need approval>

## Gaps
- <missing smoke test / no staging env / migrations not handled>