Nowadays, companies are looking to work with a delivery pipeline that ships changes quickly and also focuses on making releases “boring” because they’ve become reliable and predictable. These are key characteristics to deploy software continuously with more confidence and treat releases as a routine activity.
David Farley and Jez Humble already talked about shipping software continuously back in 2010 in Continuous Delivery. In that book, you find a lot of practices that are still relevant today. So, this isn’t a new concept, yet many organizations struggle to implement it in their delivery pipeline.
Therefore, in this post, you’ll find the concepts to help you understand better how to implement industry practices to improve the feedback you get after every release to production.
What Is Continuous Deployment?
Let’s start by defining what continuous deployment is.
The idea behind a deployment is to use it as one way of getting feedback from customers. Every time a deployment happens, you maximize feedback. However, to get valuable and real feedback, you need to get it from the consumers of your software. Therefore, you need to release a change to a production environment. And that’s what continuous deployment is about—doing safe rollouts of the code to a production environment in a continuous way, without any manual verification. Everything happens in an automated fashion.
At this point you might be thinking that this sounds good in theory, but in practice no one is doing it. Well, companies like Netflix, Etsy, and Tesla are practicing continuous deployment to release software changes for their customers. Releasing software is how companies make sure they’re building the right things, translating it into service or product improvements because you get feedback promptly with real usage. And this is basically the difference between continuous delivery and continuous deployment.
How's It Different From Continuous Delivery?
A common misunderstanding is believing that continuous delivery is the same as continuous deployment. But there’s a difference, and it’s related to the moment you release a change.
Continuous delivery is the ability to have software changes at a state that it’s ready to be released. This means that there’s a pipeline where all tests have passed, and there’s no pending work to do. The software changes become a good candidate for a release.
Continuous deployment is basically a release strategy for continuous delivery. If a change is ready to be deployed, then it’s pushed to a live environment automatically (release). You can’t practice continuous deployment without continuous delivery, but continuous delivery is the first step. Therefore, to get to the point of releasing changes automatically, rapidly, securely, and in a safe (boring) manner, there are certain crucial practices you need to implement first, starting with continuous integration.
Why Is Continuous Integration Critical?
Continuous integration is a very important practice that helps you build a pipeline that both ships software automatically and also focuses on quality. There are three basic rules of continuous integration:
Software is built from a single branch from the code repository
The pipeline uses an automated suite of tests that are reliable
If the build is broken, integration stops and the changes are rolled back
With this, you make sure that every change is a candidate for a release to production, even if you defer this decision to a different moment in time or environment.
The most important rule is to have automated tests that you can trust. Additionally, you’ll want to have tests that run quickly (hopefully in parallel) and tests for all the important scenarios for your application, like the happy path, data that broke production in the past, and incorrect input data. You don’t necessarily need to have 100% of code coverage, but you have to progressively increase the number of tests you run before declaring a software change ready.
There are going to be times when things go sideways (and it’s expected). That’s why it’s important that you have the ability to fix a problem right away. Never leave the pipeline broken. The idea is to leave the pathway free in case you need to make an emergency change and be able to continue using the automated pipeline you’ve built. Of course, you don’t get to that point overnight. You need to have a continuous improvement mindset. That’s how you’ll succeed. But let’s dive a little bit more on how to implement continuous deployment.
How Do I Successfully Implement Continuous Deployment?
The first step is to get experience working in small batches. Don’t wait to accumulate enough changes or significant changes to release something to production. Rome wasn’t built in one day. The smaller the changes, the easier and faster it becomes to test and deploy them. Moreover, you get the chance to practice more frequently until you reach a point when it becomes stable.
Tooling is important, too. You need to have something that helps you build, test, package, deploy, and release software in an automated way. Platforms like CloudBees help you with every aspect discussed in this post.
Practices like feature management, where you can decide to enable software changes to customers with one click, are of tremendous help. This is how you make code ready to be released even if it’s incomplete. You could turn on a feature for testing purposes, or only to a certain segment to run A/B tests, experiments, etc. All of this is possible, always with the idea of getting valuable feedback promptly and producing better software with every release.
It’s important that you practice continuous deployment with a clear purpose like innovating, increasing software quality, or releasing features timely. Even if you have a constraint that doesn’t allow you to practice continuous deployment, being technically ready for it will help you to reduce the time and effort for every release.
Takeaways
To summarize, continuous deployment is the ability to release software changes automatically without any human intervention. You need to rely on a good suite of tests as this will help you to gain confidence. Moreover, taking small steps by breaking big changes into smaller ones will allow you to practice more and reduce the risk of things going sideways (easy to rollback as well).
You don’t get to practice continuous deployment overnight. There are a series of steps that you need to take first. To put a name and order to each step, it could be something like: continuous integration, continuous delivery, and continuous deployment. You can also start practicing with a development or testing environment—it doesn’t have to be production right away. But you need to understand what you want to achieve—for example, fast time to market, short lead time, more experimentation.
You can always have a final gate of manual approval if you require (e.g., for compliance, mobile app stores, medical devices), but that would be continuous delivery, and it’s OK, too. The practices and tooling mentioned in this post are applicable, no matter the industry or type of workload you have.
This post was written by Christian Meléndez. Christian is a technologist that started as a software developer and has more recently become a cloud architect focused on implementing continuous delivery pipelines with applications in several flavors, including .NET, Node.js, and Java, often using Docker containers.