We know that Continuous Delivery can improve organizational performance — organizations tend to be more productive and more profitable when they adopt Continuous Delivery practices[1]. We might also assume that organizations that have gotten good at Continuous Delivery want to maximize these benefits by “turning it up to 11” and moving to full-on Continuous Deployment. I certainly assumed that when I started research for my CD in the Wild report.

It turned out I was wrong. Of the teams I spoke with who are practicing Continuous Delivery, the vast majority were not practicing Continuous Deployment. Let’s explore why that might be.

NOTE: This visual from the wonderful book Accelerate illustrates how engineering practices can drive organizational outcomes in more detail.

Continuous Delivery vs. Continuous Deployment

First up, let’s define some terms. Continuous Delivery is a set of practices built around a central principle: your code is always kept in a deployable state. You should be comfortable with any change that lands on your mainline integration branch being deployed to production. The aim of Continuous Delivery is to make production changes safe and routine. Deploying to prod should be a boring non-event that is performed as often as needed.

Continuous Deployment takes these ideas and pushes them further. Rather than each change on mainline being potentially deployable, each change is automatically deployed, with no human intervention, as soon as it passes automated quality checks. A crazy-sounding idea, but one that many organizations have had success with, for over a decade now.

These two concepts are closely related — Continuous Deployment is a specific application of Continuous Delivery practices — and they are sometimes confused with one another (sharing the same “CD” acronym probably doesn’t help matters). Some people say “Continuous Deployment” when they mean “Continuous Delivery”, and some people think that Continuous Delivery implies Continuous Deployment.

Benefits of Continuous Deployment

Why would a team want to go all the way to Continuous Deployment? One big reason is it encourages small batch sizes. The ability to make frequent, small releases to production is a key benefit of Continuous Delivery, and Continuous Deployment makes this a team’s default way of working.

Continuous Deployment also forces teams to get really serious about automation and taking humans out of the loop. This is a good thing! We want our deployment processes to be repeatable, consistent, and fast — something that machines are much better than humans at.

Costs of Continuous Deployment

It turns out, however, that getting humans out of the way is expensive. Fully automating your test and deployment processes requires a significant investment and one that is ongoing. Beyond test and deploy, there is also a need for sophisticated production monitoring and alerting, since you can no longer rely on an engineer simply keeping an eye on production metrics after they roll out a change.

Continuous Deployment also requires more discipline. While the rapid tempo of production deployments is beneficial, it also demands a new set of engineering practices. You’ll be shipping half-finished features to production which haven’t been fully tested. While this might sound scary, Trunk-based Development techniques such as Feature Flagging make it work, by protecting users from incomplete work while still providing access for internal testing. These techniques come with a learning curve, and add a small additional cost to development.

Get the Benefits of Continuous Deployment Without the Costs

I’ve talked with a lot of teams that are succeeding with Continuous Delivery but haven’t gone all the way to Continuous Deployment. When I ask them why not, they often tell me that it would require a prohibitively expensive level of deployment automation.

However, what I’ve also noticed is that many of these teams are, in fact, reaping most of the benefits of Continuous Deployment that I laid out above. They’re releasing changes to production at least every day, so clearly their batch sizes are small. What’s more, to achieve that frequent tempo these teams have automated most of their testing and deployment, and so are already seeing a lot of the benefits of a fast, consistent process. In fact, most teams are practicing fully-automated Continuous Deployment, but limited to a pre-production environment.

In many cases, the only thing preventing these high-performing teams from claiming the crown of Continuous Deployment is that they haven’t automated the “deploy to prod” button, and haven’t brought their production monitoring and alerting to the sophistication that a totally hands-off deployment process would require.

I would argue that these teams are successfully riding the cost/benefit curve. They’re implementing a lot of the practices that full-on Continuous Deployment would require — and reaping the benefits of these practices — but opting to not implement the expensive “last mile” of automation and production instrumentation which would be required to support a fully-automated deployment process. They’re choosing an appropriate level of automation.

Stick to Your Principles

So, teams that understand the value behind Continuous Delivery principles can get most of that value without paying the full cost of Continuous Deployment. Understanding these principles is key though. When teams take too many shortcuts they can end up discarding the very practices which are providing the value.

To help you avoid this trap, here are some attributes of your delivery process which you should consider non-negotiable if you want to get the value of Continuous Delivery, based on what I’ve seen successful teams doing.

1. Avoid long-lived feature branches (no more than a few days).
2. Implement fully-automated Continuous Deployment to a shared staging environment.
3. Keep that staging environment as close to production as possible.
4. Avoid release branches. Instead, build a pipeline which promotes artifacts through environments.
5. Deployment to production should be a “push-button” operation — monitored by a human but fully automated.
6. Press that button as frequently as you can. Engineers should be deploying their features to production as soon as possible once they’re completed.

Continuous Deployment: A Worthy Goal with Benefits Along the Way

Continuous Deployment is Continuous Delivery turned up to 11, and it’s a great goal to strive for. Teams that invest in making it work see a lot of benefits. However, if you stick with the fundamental principles of Continuous Delivery you can get most of those benefits long before you reach that promised land of fully-automated production deployments.

Learn More about Continuous Deployment, Continuous Delivery, and How to Test Safely in Production

Along the way in this post we linked to a number of great resources that can help you level up your CI/CD game. If you’re looking for even more, check these out:

• Continuous Delivery in the Wild — an O’Reilly report
• Pros and Cons of Canary Release and Feature Flags in Continuous Delivery
• Engineering Burnout: What is it, and How Experimentation and Continuous Delivery Can Help
• Release Frequency: A Need for Speed

And as always, for more great content follow us on Twitter @SplitSoftware, and subscribe to our YouTube channel.

Get Split Certified

Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.

Switch It On With Split

The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today, schedule a demo, or contact us for further questions.