CI vs. CD vs. Continuous Deployment

The plain-language idea

"CI/CD" gets said as one word, but it's actually up to three separate practices, and they answer three different questions:

• Continuous Integration (CI) — every time someone pushes code, does it get automatically built and tested against everyone else's latest code? This is about catching problems early, not about shipping anything.
• Continuous Delivery (CD) — is the codebase, at every point in time, in a state that could be released with one click? This adds an automated release-readiness guarantee on top of CI, but a human still decides when to actually push the button.
• Continuous Deployment (also CD, confusingly) — does every change that passes the pipeline go to production automatically, with no human in the loop at all?

The three build on each other in order: you can't have reliable Continuous Delivery without Continuous Integration underneath it, and you can't have Continuous Deployment without Continuous Delivery underneath that. But most real teams stop at Continuous Delivery on purpose — automatic production releases are a deliberate, sometimes risky choice, not the "more mature" default.

See it in a real thing: three teams, three pipelines

Same trigger — a pull request merges to main — three different endings:

# Team A: Continuous Integration only
on:
  push:
    branches: [main]
jobs:
  verify:
    steps:
      - run: pnpm install --frozen-lockfile
      - run: pnpm test
      - run: pnpm build
# ...and that's it. Nothing gets deployed. A green check just means
# "this is safe to merge," full stop.

# Team B: Continuous Delivery
on:
  push:
    branches: [main]
jobs:
  verify:
    steps: [ ...same as Team A... ]
  package-release:
    needs: verify
    steps:
      - run: pnpm build
      - run: docker build -t app:${{ github.sha }} .
      - run: docker push registry.example.com/app:${{ github.sha }}
      # A deployable, tagged artifact now exists and is sitting in the
      # registry. Someone still has to click "deploy" to ship it.

# Team C: Continuous Deployment
on:
  push:
    branches: [main]
jobs:
  verify:
    steps: [ ...same as Team A... ]
  deploy:
    needs: verify
    steps:
      - run: docker build -t app:${{ github.sha }} .
      - run: docker push registry.example.com/app:${{ github.sha }}
      - run: kubectl set image deployment/app app=registry.example.com/app:${{ github.sha }}
      # Merged to main at 2:14pm, live in production at 2:17pm.
      # No human clicked anything.

All three teams can honestly say "we do CI/CD." They mean three different things by it.

What people usually miss

Watch out

• "CD" is ambiguous on purpose in casual speech, but not in an interview. Delivery and Deployment get collapsed into the same acronym constantly. If asked to define CI/CD, name both meanings of the second C explicitly — it signals you actually know the distinction rather than reciting a buzzword.
• Continuous Integration doesn't require deploying anything. Teams that only run tests and builds on every push, with zero automated release step, are doing real, complete CI. It's a valid endpoint, not a half-finished pipeline.
• Continuous Deployment isn't "better" — it's a different risk trade-off. Skipping the human gate means faster feedback loops but zero last-look chance before users see a bug. Mature Continuous Deployment setups compensate with feature flags, canary releases, and fast automated rollbacks — not by having more confidence in the code.

The genealogy: what makes any of this trustworthy

None of these three practices mean anything without a pipeline that actually enforces them — stages of work that run automatically on a trigger and block progress when something fails. That structural idea, of a pipeline built from ordered jobs and steps, is the next lesson, and it's what turns "we do CI" from a claim into something a team can actually prove.