Continuous Delivery
Every change is automatically prepared for release. A human still presses the button to actually ship to production.
Continuous Delivery is the responsible cousin of Continuous Deployment. Every change goes through the same automated build, test, and release-preparation pipeline (the CI/CD backbone). The artifact that comes out is shippable. Whether it actually ships is a human call.
The reason most teams stop at CD instead of going to full Continuous Deployment: the cost of a bad deploy is high enough that one human in the loop is worth the latency. Move to Continuous Deployment when your monitoring, test coverage, and rollback story are good enough that the human is no longer adding signal.
Worked example of choosing per service, not per company: the same business runs a marketing site and a payments ledger. The marketing site is a great fit for full Continuous Deployment, where a bad deploy means a typo and a rollback is trivial, so every green build can ship unattended. The payments ledger stays on Continuous Delivery with a human pressing the button, because a bad deploy there moves money incorrectly and the human is genuinely adding signal, not just latency. Treating “should we automate deploys” as one company-wide decision is the mistake; it is a per-service risk judgement.
There is a regulatory dimension worth naming. In domains with change-control or audit requirements (finance, health, anything touching personal data under GDPR), the human approval step in Continuous Delivery is not just risk management, it is often the documented control an auditor expects to see: who approved this release, against what evidence, when. Teams in those settings should not chase full Continuous Deployment as a maturity badge; the manual gate is a feature their compliance story depends on. Automate everything up to the button, then keep the button where the audit trail needs it.
The honest trade-off: Continuous Delivery buys you most of the speed of full automation while keeping a human veto on the irreversible step, at the cost of that veto being a bottleneck if the human is slow or absent. The prerequisite for graduating past it is real, not aspirational: a TDD-backed suite the team will ship behind, a minutes-not-hours rollback, and an on-call rotation. Without those three, “Continuous Delivery” is a button nobody dares press, and the pipeline is decoration on top of an otherwise healthy SDLC.