Continuous Delivery vs. Continuous Deployment
Getting software into production demonstrates that you can deploy it. Continuous delivery asks whether you keep it ready to deploy as development continues. That readiness has to survive the changes you make between releases.
Consider a team that deploys every Friday. On Thursday, they run regression tests, fix what broke during the week, and check the deployment instructions. By Friday afternoon, the software is in production. They have done this successfully for months.
Now suppose they need to release on Tuesday. Thursday’s work still stands between them and production. Their weekly deployment succeeds because they set aside time to make the software releasable. Between those preparation periods, they cannot confidently choose to release.
To gain that choice, the preparation has to happen as the software changes. The regression tests that find Thursday’s failures need to run early enough for those failures to be fixed with the changes that caused them. Checking how a change will deploy becomes part of completing it. Work that previously made the release ready now keeps each change ready.
A deployment pipeline supports that shift by repeating the build, test, and deployment checks for each change. It can build a versioned artifact, run the regression tests, and deploy that artifact into a production-like environment. The same artifact can then reach production through a tested, automated process. Tuesday’s release no longer needs someone to reconstruct Thursday’s preparation.
That only holds while the checks pass and provide enough evidence to support releasing. If a regression fails and the team keeps adding changes without fixing it, the repair work starts accumulating again. Preserving readiness means restoring it when it breaks. Human testing still contributes to that evidence, but it happens throughout development instead of waiting for release day.
With that work happening continuously, Friday changes meaning. The team can still choose Friday as its release day. It now spends the intervening days with software it could release, rather than software it must first prepare.
The approval on Friday changes meaning too. The person approving the release can decide whether now is the right time, knowing the engineering work is complete. If approval still triggers a round of testing and repair, the decision remains dependent on preparation. Adding an approval button to a pipeline does not establish continuous delivery.
This is the control over timing that Dave Farley and Jez Humble describe. In Humble’s explanation of their terminology, continuous delivery keeps software production-ready so the business can choose when to release it. The schedule follows that choice because engineering readiness no longer dictates the date.
Once the team has that capability, it can also decide that each change should go to production as soon as the checks pass. The pipeline then proceeds automatically, without waiting for Friday or a person’s approval. That is continuous deployment. It builds on continuous delivery by automating the production deployment decision.
Whether to automate that decision follows from what the approval contributes. If it represents a timing judgment the checks cannot make, retain it. If passing the checks is sufficient authorization to deploy, the pipeline can proceed. This concerns putting code into production; deciding when users see a feature can remain separate through feature flags.
Either choice relies on the same readiness. A team still doing Thursday’s repair work has that work ahead of it regardless of who presses the deployment button. Its next step is to bring one recurring piece of release preparation into everyday development, then another, until choosing to release no longer starts a new engineering task.
Keeping software releasable gives you a genuine choice about when to deploy it, including the choice to make deployment automatic.