What is the difference between CI and CD

System-design interviews: Interviewers ask about deployment strategies (blue-green, canary, rolling) — you can't answer well without knowing where CD fits. Expect questions like "how would you ensure zero-downtime deploys?" — the answer starts with a working CD pipeline.

On-call: When an incident is "bad deploy," the first question is how fast you can roll back. Teams with Continuous Deployment need automated rollback or feature flags; teams with Continuous Delivery need a one-click revert. Understanding which model your org uses shapes your incident playbook.

Real systems: GitHub Actions, GitLab CI/CD, CircleCI, and Jenkins all implement both halves. Most SaaS companies (Netlify, Vercel, Heroku) default to Continuous Deployment for frontend. Most regulated industries (finance, healthcare) stop at Continuous Delivery and require a manual approval gate. Netflix and Amazon famously practise Continuous Deployment at scale, shipping thousands of times per day across services.

The Three Practices, Precisely

Continuous Integration (CI)

CI has a precise definition from its XP/agile origins: developers integrate their work into a shared mainline multiple times per day, and each integration is verified by an automated build and test suite.

The key mechanism is the merge trigger pipeline:

Developer pushes a branch and opens a pull request.
The CI server clones the repo, installs dependencies, compiles (if needed), runs unit tests, integration tests, linters, and static analysis.
A pass/fail signal comes back — typically within 2–10 minutes for a healthy pipeline.
The branch can only merge on green.

The discipline CI enforces is small, frequent merges. Long-lived feature branches defeat CI's purpose: when you finally merge a two-week branch, you're integrating a large delta and the feedback latency is retroactive. The value comes from keeping the diff small so failures are easy to attribute.

CI artifacts are typically: a built binary or container image, a test report, and a coverage report. These are inputs to the next stage.

Continuous Delivery (CD — the first kind)

Continuous Delivery extends the pipeline: after a green CI run, the artifact is automatically deployed to a staging or pre-production environment and subjected to further tests (smoke tests, acceptance tests, performance benchmarks). The critical property is:

Every build that passes all automated gates is releasable to production at any time.

The pipeline can deploy to production, but it stops and waits for a human to press a button. This gate isn't a sign of distrust in the automation — it's a business decision. The question "is now a good time to ship?" (before a holiday, during a sales event, while oncall is at lunch) is answered by a human.

The Jez Humble / Dave Farley formulation (from the book Continuous Delivery, 2010) is clear: if deploying to production requires more than clicking one button — if it requires a release document, a CAB meeting, a maintenance window — you are not doing Continuous Delivery.

Continuous Deployment (CD — the second kind)

Continuous Deployment removes the human gate entirely. Every commit that passes the full automated pipeline is deployed to production without manual intervention.

This requires a higher bar on the pipeline itself:

Automated rollback or the ability to push a quick revert commit.
Feature flags so incomplete work can ship in a dark state.
Canary or blue-green deployments so a bad release hits a small traffic slice before full rollout.
Observability — you need to detect a bad deploy within seconds or minutes, not hours.

The cultural implication: developers own the full lifecycle. "It shipped" and "it's working in production" are no longer separated by a release ceremony.

The Pipeline Model

Think of it as a linear pipeline of stages, each a quality gate. Artifacts only advance if the stage passes:

commit → [build] → [unit tests] → [integration tests] → [staging deploy] → [smoke tests] → (human gate?) → [prod deploy]

Everything up to and including staging deploy is Continuous Delivery.
Remove the human gate and you have Continuous Deployment.
Stop before staging deploy (or don't have it) and you're only doing CI.

Why the naming is confusing

"CI/CD" is used as a single phrase in job postings, tooling docs, and architecture diagrams — which collapses the distinction. In practice, most teams use it to mean "we have some automated tests that run on push" (CI only). Tooling vendors (GitHub Actions, GitLab) label their entire product "CI/CD" regardless of whether you've configured a production deploy.

The meaningful distinctions to hold:

	CI	Continuous Delivery	Continuous Deployment
Trigger	Merge/PR	Green CI run	Green CI run
Destination	Test result + artifact	Staging env	Production
Human step	Code review	Press deploy button	None
Rollback owner	N/A	Human or automation	Automation required

What makes a pipeline production-grade

Fast feedback loops: A CI pipeline that takes 40 minutes defeats the point. Engineers stop waiting for it, merge anyway, and break the main branch. Target sub-10-minute CI for most repos.

Hermetic builds: The build should produce the same artifact regardless of when or where it runs. Pinned dependency versions, reproducible container layers, deterministic test ordering.

Trunk-based development: CI works best when everyone merges to main frequently. Feature branches longer than a day or two are a smell. Feature flags enable trunk-based development for work-in-progress features.

Deployment is not release: In a mature CD setup, deploying code (getting it running in production) is decoupled from releasing a feature (making it visible to users). Feature flags handle the decoupling. This lets you deploy continuously without forcing every user-facing change to be immediately live.