CI vs Continuous Delivery vs Deployment

Three terms get thrown around as if they are the same thing: Continuous Integration, Continuous Delivery, and Continuous Deployment. They are related, they build on each other, and the abbreviation “CD” can mean either of the last two. That overlap is exactly why people get confused. This page pulls the three apart so you know precisely what each one means, where one ends and the next begins, and which one your team actually needs.

The one-sentence definitions

Let’s start with the shortest honest definitions, then unpack them.

Continuous Integration (CI) — developers merge their code into a shared branch often (many times a day), and an automated build and test run checks every merge.
Continuous Delivery (CD) — every change that passes CI is automatically prepared into a release-ready artifact, so you could deploy to production at any moment with a single button press.
Continuous Deployment (also CD) — every change that passes all automated checks goes to production automatically, with no human pressing a button.

An artifact here just means the packaged, ready-to-run output of your build — a Docker image, a .jar file, a zipped bundle, etc. A pipeline is the automated sequence of steps (build, test, deploy) that runs on every change.

The key difference between the two “CD”s is a single thing: who decides to ship to production. In Continuous Delivery, a human clicks deploy. In Continuous Deployment, a machine does it the moment tests pass.

The full comparison

Aspect	Continuous Integration	Continuous Delivery	Continuous Deployment
Goal	Catch integration bugs early	Always have a releasable build	Ship to users continuously
Merges code often?	Yes	Yes	Yes
Runs automated tests?	Yes	Yes	Yes
Builds a deployable artifact?	Not required	Yes	Yes
Deploys to staging automatically?	No	Yes	Yes
Deploys to production	No	Manual (button/gate)	Automatic
Human approval to release?	N/A	Yes	No
Needs strong test coverage?	Helpful	Important	Critical
Typical for	Every team	Most professional teams	Mature teams, high test confidence

Notice that each column includes everything in the column to its left. You cannot do Continuous Delivery without Continuous Integration, and you cannot do Continuous Deployment without Continuous Delivery. They stack.

The pipeline, described in words

Picture a single code change flowing left to right through your pipeline. A gate is a checkpoint that must pass before the change moves on.

Developer pushes commit / opens pull request
        │
        ▼
[ Continuous Integration ]
   • checkout code
   • compile / build
   • run unit + integration tests
   • run linters and security scans
   • merge to main if green   ◀── CI ends here
        │
        ▼
[ Continuous Delivery ]
   • build the release artifact (e.g. Docker image)
   • push artifact to a registry
   • auto-deploy to a staging environment
   • run smoke / acceptance tests
   • ⏸  WAIT for a human to approve   ◀── manual gate
        │
        ▼ (human clicks "Deploy")
   • deploy to production
        │
   ──────────────────────────────────
        │
[ Continuous Deployment ]
   • everything above, but the ⏸ gate is removed
   • if staging tests pass, production deploy fires
     automatically — no human in the loop

The whole disagreement between the two CDs lives at that ⏸ pause. Remove the pause and Continuous Delivery becomes Continuous Deployment.

When to use which

You almost never “choose” CI — every team should do it. The real decision is how far down the chain you go.

Rule of thumb: never automate a step you do not trust. If your automated tests would not catch a serious bug, do not let a machine push straight to production. Build trust in your test suite first, then remove the manual gate.

Use Continuous Delivery (manual gate) when:

Your product is mission-critical and a bad deploy is expensive (banking, healthcare, billing).
You have compliance rules that require a human sign-off before release.
Your automated test coverage is good but not yet airtight.
A business reason controls timing (marketing launch, maintenance window).

Use Continuous Deployment (fully automatic) when:

You have strong, fast, reliable automated tests you genuinely trust.
You can roll back quickly and safely (feature flags, blue-green or canary deploys).
You want the shortest possible time from “code written” to “users benefit”.
Small, frequent changes are the norm — each deploy is tiny and low-risk.

Gotcha: Continuous Deployment without good monitoring and an instant rollback is a foot-gun. If a broken change reaches users automatically, you need to detect and undo it in minutes, not hours.

A concrete example on Ubuntu

Say you run a self-hosted runner on an Ubuntu 22.04 server. The CI part is the same regardless of which CD strategy you pick — install dependencies, then test:

sudo apt update
sudo apt install -y nodejs npm
npm ci
npm test

Output:

Test Suites: 14 passed, 14 total
Tests:       118 passed, 118 total
Time:        9.42 s
Done in 11.03s.

That green test run is your CI gate. What happens next is the only thing that separates the three terms:

Stop here, merge only → Continuous Integration.
Build an artifact and wait for approval → Continuous Delivery.
Build an artifact and auto-deploy → Continuous Deployment.

For example, the Continuous Delivery step might publish a Docker image but stop before production:

docker build -t registry.example.com/app:1.4.2 .
docker push registry.example.com/app:1.4.2
echo "Artifact ready. Awaiting manual approval to deploy."

Under Continuous Deployment, that same script would simply continue and run the production deploy command instead of waiting.

Best practices

Always do CI first — fast, automated build and test on every merge — before reaching for either CD.
Keep pipelines fast; a CI run over ~10 minutes discourages frequent merging, which defeats the point.
Build the artifact once and promote that same artifact through staging to production — never rebuild per environment.
Treat your test suite as the real gatekeeper: the safety of removing the manual gate depends entirely on test quality.
Add monitoring and a one-command rollback before you switch from Continuous Delivery to Continuous Deployment.
Use feature flags so you can deploy code “dark” (off by default) and turn features on independently of deploys.
Be precise in conversation: when someone says “CD”, confirm whether they mean Delivery (manual) or Deployment (automatic).