Continuous delivery
Keeping every validated change packaged and ready for production, while a person or business decision still chooses when to release it.
What it is
Continuous delivery keeps every change that passes the pipeline in a releasable state. The code is integrated, tested, packaged as an immutable build, and usually deployed to a production-like environment. A person or business decision still chooses when that exact build goes to production. Jez Humble and David Farley's 2010 book *Continuous Delivery* gave the practice its durable name.
Reach for it when releases need a scheduled launch, a compliance approval, or a product decision, but the engineering work should be ready at any moment. Small changes and a reliable pipeline matter more than how often the release button is pressed.
Gotcha: continuous delivery is not continuous deployment. If the production step has no human decision and every passing change ships automatically, that is continuous deployment. A release branch that sits for weeks, or a production build rebuilt by hand, also breaks the promise that the validated artifact is ready to go.
Ask AI for it
Set up continuous delivery with GitHub Actions. On every pull request and push to main, run lint, typecheck, tests, and the production build, then store one immutable artifact named with the commit SHA. Deploy that artifact automatically to staging. Add a production job triggered by workflow_dispatch with a required commit_sha input and protected by a GitHub Environment approval, then promote that commit's stored artifact without rebuilding it. Run a smoke test after promotion and document how to redeploy the previous artifact.