When to Release to Production: Distinguishing Continuous Delivery and Continuous Deployment

One of my favorite descriptions of continuous delivery is that we work continuously and keep our software in a releasable state, but this does not specify when the change should actually be pushed to production. A common assumption is that continuous delivery implies continuous deployment, which forces us to decide what to release and how often.

Hi, I am Qiao Liang, author of "Continuous Delivery 2.0", and I invite you to follow my public account.

Now I want to explore the decision of releasing to production. A good way to think about continuous delivery is that we aim to maximize feedback, and different levels of feedback matter to us.

We are interested in technical feedback on change quality, which we can obtain from the pipeline’s effectiveness, proving that we are building the right thing.

We also care about product feedback, answering whether what we built is correct for users.

The deployment pipeline gives us a repeatable, reliable way to ensure we build the right thing; if a change passes the pipeline and performs well, we are in a great position to move forward.

However, the only way to verify that we built the right thing is to release it and observe user reactions.

We are discussing the difference between continuous delivery and continuous deployment. Continuous deployment is a valuable release strategy for continuous delivery but not the only one; if the pipeline indicates a change is ready, it is releasable.

We can choose to trigger deployments automatically or deliver manually. If all automation runs smoothly, continuous deployment means simply pushing to production.

Many think continuous delivery is just about continuous deployment, but there is more; they are closely related. You can practice continuous delivery without continuous deployment, but without continuous delivery you cannot truly practice or control continuous deployment.

Practicing continuous deployment is ideal, but it starts with a healthy deployment pipeline that determines releasability. Smaller, more frequent releases reduce risk; Amazon releases changes every 11.2 seconds, cutting issue‑resolution time by 90% because each change is smaller and simpler.

If every successful commit is automatically pushed to production, we become more cautious with each commit. The total risk of releasing changes is a function of change size and frequency; more frequent, smaller releases lower risk, while interactions between multiple changes can increase risk exponentially.

Most of the time continuous deployment is the best strategy, but not always; sometimes business or regulatory constraints dictate when updates should occur, such as in safety‑critical environments like trucks where drivers may not want updates at night.

Thus, release decisions are often business decisions rather than purely technical ones. When appropriate, teams can release a minimum viable product to internal or friendly users to gather feedback and validate the product.

Various strategies can ensure we build the right product, from regulated financial exchanges to internal weekly releases using mock tokens, allowing teams to learn from real usage rather than speculation.

Considering both technical feedback (continuous delivery) and product feedback (continuous deployment) provides valuable insights that help adjust methods to meet business needs.