Continuous delivery vs continuous deployment: the diagram differs by one gate

Draw the shared spine once: commit, build, test, publish to the registry, deploy to staging, verify. Continuous delivery adds a gate node after verification, and the artifact waits in the registry until someone opens it. Continuous deployment replaces that gate with an automated check and the artifact continues.

Because the two share everything to the left of the gate, the honest way to document both is one diagram with the gate marked as the variation point. A team practising delivery today and planning deployment next year does not need two pictures, it needs one picture and a note about which shape is going to change.

The corollary matters more than the definition: continuous deployment is not a bigger version of continuous delivery, it is the same pipeline with the human removed. Removing the human is only safe when the checks that were implicitly delegated to that human are drawn as explicit nodes.

The gate needs three attributes on it: who can open it, what the timeout does, and whether the person who wrote the change can approve it. "Manual approval" alone hides the only interesting parts. "Approval, release managers, 48h to auto-reject, self-approval blocked" is one label and answers a compliance question without a second document.

Read the timeout out of the product rather than assuming it. An Azure Pipelines approval defaults to a 30 day timeout, can be set as high as 365 days, and marks the stage skipped rather than failed when it expires. A release that quietly skips production a month after nobody clicked approve still shows a green run, so "timeout 30d, then skipped" and "timeout 48h, then rejected" describe two different systems and the label has to say which one you have.

The artifact should be shown waiting, not being rebuilt. The defining property of continuous delivery is that the thing tested in staging is byte for byte the thing that reaches production. A diagram that shows a second build step after the gate is documenting a different, weaker practice, and it is worth noticing that on paper.

Draw the queue if there is one. When approvals happen weekly and merges happen daily, several artifacts wait at the gate at once and production receives a batch. That batching is where most delivery pain comes from, and it is visible on the diagram as soon as you draw the waiting artifacts rather than a single arrow.

Remove the gate and the diagram immediately looks too simple, which is the tell. Everything the approver used to do has to appear as a node: a smoke test against staging, a progressive rollout with a traffic percentage, a bake period with a duration, and an automatic rollback triggered by an error rate or an error budget burn.

Those nodes carry numbers, and the numbers are the documentation. "Canary 5 percent, 15 minute bake, roll back on 5xx above 0.5 percent" tells a reader more about your risk posture than any paragraph. It also makes the diagram falsifiable: if the deploy config says ten minutes, someone will notice.

Draw the abort path as a real edge back to the previous revision, with its trigger on the label. A continuous deployment diagram without a rollback edge is describing a system that has never had a bad deploy, which is not a system anyone has.

Continuous delivery      commit -> build -> test -> publish -> staging
                         -> [GATE: release managers, 48h] -> production

Continuous deployment    commit -> build -> test -> publish -> staging
                         -> smoke -> canary 5% (bake 15m) -> production
                                        |
                                        +-- 5xx > 0.5% --> rollback to previous

The usual real answer is per environment: continuous deployment to dev and staging, continuous delivery to production. Some teams go further and split by change class, deploying configuration and feature flags automatically while gating schema migrations and infrastructure changes.

Draw that as it is. Zones per environment with a gate only on the boundary that has one, and, if change classes differ, a dashed lane with its condition written on it. A single label at the top of the diagram saying "continuous delivery" when three of four environments are fully automatic is the kind of small inaccuracy that makes readers stop trusting the whole page.

When the model changes, the diagram is one shape away from being correct. That is a good reason to keep it in a tool where a shape can be changed and republished rather than in an exported image, and to publish it through an embed so the handbook page follows.

• Environments and approval gates
• How to draw a CI/CD pipeline diagram
• What belongs in a CI/CD pipeline diagram
• DevOps pipeline diagram