METHODOLOGY

Continuous Delivery

Every change is automatically prepared for release. A human still presses the button to actually ship to production.

Last reviewed: 2026-05-24 byKevin Riedl wiki β†—

Continuous Delivery is the responsible cousin of Continuous Deployment. Every change goes through the same automated build, test, and release-preparation pipeline. 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.

// FAQ

FAQs

FAQs

CD when the cost of a bad deploy is high enough that a human-in-the-loop adds signal. Continuous Deployment when monitoring, rollback, and test coverage are mature enough that the human is just adding latency. Most teams should aim for CD and graduate to Continuous Deployment on a per-service basis.
An automated test suite the team trusts enough to ship behind, a rollback path measured in minutes not hours, and an on-call rotation that can respond if the deploy lights something on fire. Without those three, CD is a button nobody presses.