CI vs CD vs Continuous Deployment

Introduction

Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment (CDep) are three distinct maturity steps — not interchangeable labels. CI merges and verifies every change on a shared branch. Continuous Delivery keeps main always releasable and automates promotion up to production, where a human or policy gate may still approve. Continuous Deployment removes that last human gate: every green pipeline run ships to production automatically.

The story

A fintech platform team announced "we do CD" after wiring Argo CD to sync every merge to production. Within two weeks, three regressions reached customers — including a misconfigured feature flag that doubled transaction fees. Postmortem revealed CI ran only on main, skipped integration tests on PRs, and had no staging gate. They renamed the initiative, fixed CI on every PR, added automated staging deploy with smoke tests, and kept a manual prod approval for six months. Change failure rate dropped from 22% to 5%; only then did they enable continuous deployment for low-risk services.

Understanding the topic

Three terms, one ladder: CI proves code integrates safely. Continuous Delivery proves the release path is automated and prod-ready. Continuous Deployment proves your gates are strong enough to trust machines with the final promote.

• CI scope: compile, unit/integration tests, lint, SAST — triggered on PR and merge; output is a verified commit plus artifact.
• Continuous Delivery scope: deploy same artifact to staging automatically; prod promotion is one click or approval — artifact never rebuilt.
• Continuous Deployment scope: prod deploy when pipeline green; approval replaced by automated gates (canary metrics, error budget, feature flags).
• Approval gates: GitHub environment reviewers, GitLab protected environments, manual workflow_dispatch — these belong to Delivery, not CI.
• DORA mapping: CI improves lead time for changes (early defect detection); Delivery/Deployment improve deployment frequency; strong CI+CD together reduce change failure rate and MTTR.

Internal architecture

Maturity stack — each layer assumes the one below is stable:

PR opened
   ↓
CI (every change)
   ├─ build · test · lint · scan
   └─ artifact: image@sha256:abc…
   ↓
Continuous Delivery
   ├─ auto deploy staging (same artifact)
   ├─ smoke + integration on staging
   └─ prod: manual approval OR policy gate
   ↓
Continuous Deployment (optional)
   └─ prod promote when canary SLIs green
   ↓
Observe → rollback → DORA metrics

Visual explanation

Two diagrams show where CI vs CD vs Continuous Deployment lives in the delivery path and how teams implement it in production.

Step-by-step explanation

1. Step 1 — Define CI boundary: List every check that must pass before merge: tests, lint, minimum coverage on changed files, secret scan. Run on PR; block merge via branch protection.
2. Step 2 — Produce one artifact per merge: Build container or bundle once on main; tag with git SHA and digest. This artifact is the only object that may reach any environment.
3. Step 3 — Automate staging: Deploy artifact to staging on every main merge; run smoke tests and contract tests against staging URL. Fail the pipeline if smoke fails — do not approve prod.
4. Step 4 — Choose prod gate: Continuous Delivery = required reviewer or change-advisory board for prod job. Continuous Deployment = replace human with metric gates (error rate, latency p99, business KPI).
5. Step 5 — Measure with DORA: Track deployment frequency, lead time for changes, change failure rate, and MTTR before and after each maturity step. If frequency rises but failure rate rises too, you skipped CI discipline.

Production implementation

GitHub Actions — Delivery with prod approval vs Deployment with metric gate:

• Use one workflow file with feature flags (vars.CONTINUOUS_DEPLOY) rather than forked pipelines — drift kills audits.
• Prod environment protection satisfies SOC2 "segregation of duties"; CDep requires compensating controls documented in the change policy.

# .github/workflows/payments-api.yml
name: payments-api
on:
  pull_request:
  push:
    branches: [main]

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test && npm run lint
      - run: docker build -t ghcr.io/acme/payments:${{ github.sha }} .
      - run: trivy image --exit-code 1 ghcr.io/acme/payments:${{ github.sha }}

  deploy-staging:
    needs: ci
    if: github.ref == 'refs/heads/main'
    environment: staging
    steps:
      - run: ./deploy.sh staging ghcr.io/acme/payments:${{ github.sha }}
      - run: ./smoke.sh https://staging.payments.acme.com/health

  deploy-prod-delivery:
    needs: deploy-staging
    if: github.ref == 'refs/heads/main'
    environment: production  # required reviewers in GitHub settings
    steps:
      - run: ./deploy.sh prod ghcr.io/acme/payments:${{ github.sha }}

  deploy-prod-cdep:
    needs: deploy-staging
    if: github.ref == 'refs/heads/main' && vars.CONTINUOUS_DEPLOY == 'true'
    steps:
      - run: ./canary.sh ghcr.io/acme/payments:${{ github.sha }} 5
      - run: ./watch-slis.sh --error-rate-max 0.1 --duration 10m
      - run: ./canary.sh ghcr.io/acme/payments:${{ github.sha }} 100

Execution workflow

Real-world use

Etsy and GitHub popularized "deploy on green" for internal services while keeping customer-facing paths gated. Google's TAP runs CI at scale; most product teams still use human launch calendars for high-risk surfaces. DORA's 2023 report shows elite performers deploy on demand with low failure rates — but they invest heavily in CI and automated rollback first, not auto-prod on day one.

Enterprise use cases

Global bank — tiered CD model: Retail mobile app stays on Continuous Delivery with CAB approval Friday blacklist. Internal admin APIs use Continuous Deployment to a single-region canary with automated rollback. Shared CI runs on every PR across both — same artifact registry, different prod gates.

• Policy: CDep allowed only when change failure rate < 5% for 90 days and on-call coverage 24/7.
• Audit: Pipeline logs + artifact digest + approver identity exported to SIEM for Delivery paths; CDep paths log metric gate decisions.
• DORA outcome: Internal tools reached 20 deploys/day; customer-facing app moved from monthly to weekly without raising incidents.

Production case study

SaaS billing service — from fake CD to real Delivery:

• Before: "CD" meant SSH + docker pull latest on prod; no CI on PRs; monthly outages.
• Week 1–4: PR CI with branch protection; artifact registry; staging auto-deploy on main only.
• Week 5–8: Prod job with two required approvers; rollback script tested monthly; DORA baseline captured.
• Week 12: Canary CDep enabled for read-only API routes only after change failure rate < 3% for 60 days.
• Outcome: Lead time for changes 14d → 2d; deployment frequency 2/mo → 4/wk; change failure rate 18% → 4%.

Trade-offs

• Continuous Deployment: minimal lead time and no approval bottleneck — requires exceptional test quality, feature flags, and observability; one bad gate ships customer impact in minutes.
• Continuous Delivery: human judgment for prod — adds hours or days of lead time but satisfies compliance and reduces panic deploys; risk of approval theater if staging is not trusted.
• CI-only teams: cheap to operate and easy to audit — but deployment frequency stays low and integration bugs surface late if CD is deferred too long.
• Metric gates vs human gates: metrics scale and never sleep — but poorly chosen SLIs auto-promote bad releases; humans catch context machines miss (marketing launches, known upstream outages).

Security implications

CI/CD boundary is a trust boundary: PR workflows must not access prod credentials; prod deploy jobs must not run on fork PRs.

• Separate OIDC roles: ci-build (read repo, push artifact) vs deploy-prod (mutate prod cluster) — CDep amplifies blast radius of credential theft.
• Approval gates enforce segregation of duties; removing them for CDep requires compensating detective controls (real-time anomaly alerts, auto-rollback).
• Artifact signing and provenance (SLSA, Sigstore) matter most when Delivery promotes the same binary everywhere — tampered artifact bypasses code review.

Scalability analysis

CI cost scales with PR volume; CD scales with environment count and deployment frequency. Teams hitting 500+ PRs/day shard CI with path filters and merge queues; CDep at high frequency requires deployment concurrency limits and progressive delivery to avoid thundering herds on databases.

• Merge queue (GitHub, GitLab) preserves "CI on every commit" without N parallel full builds on busy main.
• Continuous Deployment to 40 microservices needs orchestration (Helmfile, Argo Rollouts) — not 40 independent prod jobs racing.
• DORA metrics should be segmented by service tier; averaging hides a CDep internal tool masking a failing Delivery monolith.

Staff engineer insights

• When leadership says "we need CD," ask which C they mean — most pain is fixed by CI on PRs and staging automation, not removing prod approvers.
• Draw three boxes on the whiteboard (CI / Delivery / Deployment) before discussing Jenkins vs Actions — vocabulary prevents six-month toolchain debates.
• Continuous Deployment is a consequence of trust in gates, not a tool setting — if you wouldn't let an intern click "deploy prod," your metrics aren't ready either.
• Report DORA metrics per service tier; publishing one "elite" number while billing still deploys manually hides organizational debt.

Best practices

• Never rebuild artifacts per environment — CI output is the promotion unit for both Delivery and Deployment.
• Make staging a faithful prod slice (data masked, same infra module) before removing human prod approval.
• Document which services are CDep-eligible in a tier registry — default to Delivery.
• Rehearse rollback monthly; CDep without rollback is just faster incidents.

Common mistakes

• Renaming manual deploy scripts "CD" without CI on every PR — ships defects faster.
• Requiring prod approval but allowing approvers to bypass failed staging smoke — gate theater.
• Enabling CDep org-wide because a conference talk said so — start with one low-risk service.

Advanced interview questions

Hands-on exercise

Draw and label your team's current pipeline on paper. Mark each box CI, Continuous Delivery, or Continuous Deployment. Identify one step that rebuilds per environment and one missing gate. Write a one-page ADR proposing the next maturity phase with DORA metrics to track.

• Red = manual or SSH; yellow = automated but no gate; green = automated with test or metric gate.
• Share the ADR with a teammate — if they can't explain the three terms, revise the doc.

Summary

You can now distinguish CI, Continuous Delivery, and Continuous Deployment on a diagram, place approval and metric gates correctly, and tie each maturity step to DORA outcomes. In interviews and design reviews, lead with the ladder — not the tool — and argue when human prod approval still earns its place.