Continuous Delivery vs Continuous Deployment — the actual distinction

The two terms differ on exactly one axis: whether a human must approve a deploy before it reaches production. Continuous delivery keeps that approval. Continuous deployment removes it. Everything else that vendors, blog posts, and conference talks attach to the distinction - speed, automation level, culture, maturity - is downstream of that single mechanical decision, and most of it is marketing.

The single mechanical difference

A pipeline that produces a verified, deployable artifact at the end of every merge can be configured two ways. In the first, the pipeline stops at the production-bound stage and waits for a human to click a button, post a ticket, or accept a change advisory board record. In the second, the pipeline does not stop. The artifact is applied to production by the workflow itself, gated only by the tests that have already passed.

flowchart LR
    A[Merge to main] --> B[Build and test]
    B --> C[Artifact published]
    C --> D{Manual approval gate}
    D -- "yes - held" --> E[Continuous delivery]
    D -- "no - automatic" --> F[Continuous deployment]
    E --> G[Production apply]
    F --> G[Production apply]

The shape before the gate is identical in both cases. The shape after the gate is identical in both cases. The variable is the gate. Anything else that distinguishes the two terms in vendor literature is decoration.

Why the terms are conflated

The conflation is not accidental. Vendor marketing treats the two terms as interchangeable because the buying decision is usually about the toolchain (a CI/CD product), not about the gate. The gate is a process decision the buyer’s team must make, and a process decision does not sell a product. Vendors therefore collapse both terms into “CD” and let the buyer infer whichever meaning suits them.

The reading that survives the conflation:

• When a vendor says “CD” without qualification, ask which letter they mean. The answer is in their deployment workflow configuration, not in their marketing page.
• When a practitioner says “CD”, ask the same question. Many practitioners use “CD” to mean continuous deployment because the term is shorter, and then describe a continuous delivery pipeline without realising they have renamed it.
• When an auditor says “CD”, the answer is usually continuous delivery - the audit trails, change records, and sign-offs that compliance regimes require are the human approval gate, not the absence of one.

Placing the terms on one diagram

The cleanest framing puts both terms on the same pipeline with the gate as the variable element:

flowchart LR
    A[Commit] --> B[Continuous integration]
    B --> C[Artifact in registry]
    C --> D{Approval gate present?}
    D -- "yes" --> E[Delivery - held until approved]
    D -- "no" --> F[Deployment - applied automatically]
    E --> G[Production]
    F --> G[Production]

The diagram has the same inputs, the same artifact stage, and the same production target. The only difference is the gate. The gate is what makes continuous delivery safe to ship to a regulated workload and continuous deployment a maturity claim. Both terms describe fully automated pipelines; the gate is the only axis on which they differ.

Production discipline

1. Pick a term, write it down, and stick to it. A team that uses “CD” to mean both things will eventually deploy without approval because someone read the word “CD” in a vendor doc.
2. Default to continuous delivery. A gate that exists can be removed. A gate that was never there cannot be added without admitting the team was not ready.
3. Read vendor documentation for the gate, not the title. The title is marketing. The configuration is the contract.
4. Audit the gate. A “manual approval” step that has not been exercised in six months is a gate that has been silently bypassed - either because the workflow was edited, or because someone approved without reading.

Cross-course references

• This course, Part XXXVII (CIFundamentals) - lesson git-cicd-gitops-xxxvii-01-what-ci-is-and-is-not establishes that CI is automation, not gatekeeping; the gate is the structure that continuous delivery adds on top.
• This course, Part XLVIII (ConditionalExec) - lesson git-cicd-gitops-xlviii-06-environment-protection-rules describes the platform-side mechanism that implements the continuous delivery gate.
• Linux for Production Sysadmins - Part XXII (ChangeMgmt) covers the change-advisory-board record that historically functioned as the continuous delivery gate before workflow-side approval existed.

Quiz