In the absence of continuous deployment, changes must be manually approved before they are promoted (i.e., pushed or deployed) to production.

Many continuous delivery implementations automatically promote changes to a staging environment when all automated tests pass. This allows developers, testers, or other stakeholders to perform manual or exploratory testing before manually approving a push to production. Continuous deployment removes that final manual approval gate.

Benefits of Continuous Deployment

Continuous Deployment brings significant advantages, but it doesn’t come for free. Here are some of the advantages and disadvantages of choosing continuous deployment.

Advantages

The most significant advantage of continuous deployment is speed. Teams that practice continuous delivery routinely move code from developer commit to production in just a few days and often in just a few hours or minutes.

Speed, in turn, unlocks greater safety and innovation.

Safety

While it may seem paradoxical or counterintuitive that a faster process without a manual review and approval step would be safer, DevOps Research and Assessment studies have repeatedly shown that teams with a short cycle time from commit to production have significantly lower incident rates and dramatically shorter time to resolve issues. They also achieve better business outcomes, which leads to the next advantage: innovation.

Innovation

Knowing that your team can safely push another deployment in minutes when needed reduces the fear of making changes and rolling them out. This creates a virtuous cycle of faster iteration and faster learning.

Continuous deployment shifts significant amounts of power and responsibility towards the team that is writing code. This leads to another paradox: Instead of leading to reckless, unchecked behavior and decisions that don’t reflect business requirements, continuous delivery places developers closer to end-users, and that naturally leads to greater empathy, greater pride of ownership, and a more effective feedback loop when iterating towards desired outcomes.

Before we move on, take a moment to notice the contrast between continuous delivery and legacy development patterns where a development team cuts a release, passes it along to a separate testing team, which in turn hands it off yet again to an operations team to take live. The old ways diffused responsibility and placed a disproportionate amount of it in the hands of teams that knew less about the changes being made in a release and the motivations behind them.

Disadvantages

The disadvantages of continuous deployment over continuous delivery with a manual gate at the end are all related to the amount of rigor you must have in place to get the benefits.

Incomplete Implementation Just Breaks Things Faster

Without effective stakeholder review, code review, automated testing, and observability in place, continuous delivery increases the risk of things going wrong. It can lead you to the same sort of complex multi-layered problems that large batches create. It’s all the grief of merge hell but live in production. Incomplete implementations often lead to “this just doesn’t work here” reactions and a race back to old ways of doing things.

Implementation Takes Time, Commitment, and Culture

Moving to continuous deployment requires a sustained effort. The cost in time and commitment and the need to shift management and team culture from a short-term deliverable focus to a long-term process improvement focus may be too “expensive,” depending on your context. If this is so, your efforts are better spent incrementally achieving continuous delivery to the point where the manual gate at the end is just a mere formality.

Pass the Mojito Test First

If you are eager to reap the benefits of continuous deployment but your team or organization is not yet ready to implement it rigorously, consider focusing first making your quest to pass the mojito test, as described by Jez Humble, co-author of Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation:

I have a test for continuous delivery, which is, “Could I, at any point in time, press a button and take what’s in version control and ship it, with a mojito in my hand?”

Jez Humble

In other words, focus on achieving continuous delivery first. Since there’s a manual gate at the end, you can address issues with reviews and testing and overcome the limitations of less robust production observability by having developers obtain approvals and then “manually walk” changes into production one at a time. This requires more coordination, and that probably needs more waiting. Still, once you have orchestrated the automation required to pass the mojito test, you are likely ready to embark on continuous deployment.

It’s OK To Push a Button

Something to bear in mind is that even if you’ve achieved a well-defined and well-operated continuous delivery practice, you may still decide to keep a human-mediated gate before pushing to production.

In his book, Continuous Delivery in The Wild, Pete Hodgson reported that among the dozen or so teams he interviewed that were successfully using continuous delivery practices to achieve daily or more frequent pushes to production, only two had chosen to do continuous deployment. Why? Their continuous delivery practices were giving them almost all of the benefits of continuous deployment, and the large amount of additional work required to allow that automatic push at the end safely wasn’t worth the small gain they would capture. You can read more about Pete’s research on this in the blog post, You Might Not Need Continuous Deployment.

Without Automated Tests, You Don’t Have a Pipeline

It’s important to remember that any CI/CD pipeline, and especially one that does continuous deployment, cannot function without effective automated testing. Automated tests are the fuel that moves code towards successful deployment, regardless of whether that final deployment to production is automatic or done with the push of a button.

If you can’t achieve team consensus that automated testing is essential, you can’t implement continuous integration, and you don’t really have a pipeline. Don’t be fooled by a pipeline that simply kicks off automated builds upon commits or on a schedule. Read Continuous Integration: What You Don’t Know Can Hurt You to learn more about this.

Looking for more on Continuous Integration, Continuous Delivery, and Continuous Deployment? Have a look at this CI vs. CD vs. CD blog post.

If you’d like to go deeper into the underlying values that lead to success, reading real-world stories of widely different teams that have all achieved daily or more frequent pushes to production, be sure to download our eBook, Continuous Delivery in the Wild.