Continuous Delivery vs Deployment

Continuous Delivery is the capability to release any commit; Continuous Deployment automates the act. Same pipeline, different gate.

Overview

Delivery is not Deployment

Continuous Delivery (CD) and Continuous Deployment (CDeploy) are different things. The distinction shows up in interviews because most candidates conflate them.

What it is — The ability to get any change into production safely and quickly — The automated exercise of that ability
Production gate — Manual — Automatic on a green pipeline
Deploy rate — A business-driven choice — Many production deployments every day

The definitions

Jez Humble and Dave Farley defined Continuous Delivery in their 2010 book of the same name. Humble (continuousdelivery.com): "Continuous Delivery is the ability to get changes of all types — including new features, configuration changes, bug fixes and experiments — into production, or into the hands of users, safely and quickly in a sustainable way."

> [!IMPORTANT] The capability is the product. Whether you exercise it on every commit is a separate, business-driven decision.

Humble on the difference: "Continuous Deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day. Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment."

The deployment pipeline

The unifying construct is the deployment pipeline (Humble and Farley, Continuous Delivery, Ch 5): an automated implementation of the build-test-deploy process. Every change is verified at increasing levels of fidelity until it is rejected or declared releasable.

1. Commit — Compile, unit tests, static analysis; failure means the commit cannot progress — ~5 minutes
2. Automated acceptance — Deploy to a test environment, run business-readable acceptance tests — ~1 hour
3. Capacity / non-functional — Load tests, soak tests, security scans against a production-like environment
4. Manual test / UAT — Optional human sign-off; increasingly empty for mature teams
5. Release — Production deployment: manual gate (CD) or automated (CDeploy)

> [!TIP] The pipeline structure is identical for CD and CDeploy; only the production gate differs.

Why both exist

Regulatory environments (pharma, banking, defense) often forbid automatic prod pushes: every release must be human-approved. They can still practice Continuous Delivery, with every commit releasable and every build producing an audit-ready artifact, without practicing Continuous Deployment.

Key concepts

Continuous Delivery (Humble verbatim): continuousdelivery.com: "the ability to get changes of all types into production, or into the hands of users, safely and quickly in a sustainable way." The capability — every commit is releasable, every build produces an audit-ready artifact — is the product. Whether you actually push it is policy.
Continuous Deployment: Every change that passes the pipeline is automatically deployed to production. Continuous Delivery without the human gate at the end. Most teams that say they do CDeploy are actually doing CD with a low-friction Approve button.
Deployment pipeline: Humble & Farley Ch 5: an automated implementation of build → test → deploy where each stage rejects unfit candidates and promotes the rest. Single source of truth for "is this releasable." The same pipeline works for CD and CDeploy; only the final gate differs.
Build once, promote many (Factor V of 12-factor): Pipeline rule: build the deployable artifact exactly once at the commit stage and promote that same artifact through every subsequent stage. Never rebuild between stages — it invalidates earlier test signal. The byte-identical artifact tested in staging must be the artifact running in prod.
Release candidate: In CD, every commit that passes the commit stage is a release candidate. The pipeline's job is to falsify each candidate; survivors are deployable by definition. This inverts the traditional model where releases are explicit, gated events; under CD, releases are normal pipeline output.
DORA elite tier: State of DevOps reports: deploy on-demand multiple times/day; lead time < 1 day; change failure rate < 15%; restore time < 1 hour. Achievable with Continuous Delivery; common with Continuous Deployment. The bands are achievable when the pipeline shape matches the layered model.

When to use it

Distinguishing your team's capability from your team's policy in the same conversation
Justifying investment in pipeline automation when leadership wants "faster releases" but not "automatic releases"
Designing pipelines for regulated environments where auto-deploy is forbidden but releasability per commit is required
Explaining why a team that ships weekly with a green pipeline still has Continuous Delivery

Interview questions

What is the difference between Continuous Delivery and Continuous Deployment?
Why does "build once, promote" matter so much?
When should your team practice Continuous Deployment vs Continuous Delivery?
Walk through Humble & Farley's deployment pipeline stages.