What is Continuous Delivery (CD)?
Continuous delivery is a software release strategy alongside continuous integration and continuous deployment. The idea behind continuous delivery is preparing the software for delivery, often multiple times a day and thus being able to deploy new releases to users at any time. To have an efficient continuous delivery process, it’s important that continuous integration is built into your pipeline.
The code will still need to pass through a series of automated tests but the actual release into the production environment is done manually.
Therefore, continuous delivery ensures that your code is always in a deployable state to a production environment even while numerous changes are being made by multiple developers on a frequent basis.
Benefits of Continuous Delivery
Quicker release to market
Since your code is always in a state ready for deployment, this means that you can continuously release new features to production at any time. This is particularly crucial in order to respond to rapidly changing market demands so just as quickly that developers can make the necessary changes, they just as quickly can release those changes to end-users.
Just like continuous integration, when changes are released more frequently, errors are easily spotted and fixed. Developers can easily roll back any faulty releases as they are being released in small batches which are less complicated to correct in the production process.
Jez’s Humble’s page on continuous delivery outlines four main principles to achieve lower risk deployments. This includes the following:
- Low risks releases are a step-by-step process. This means that the system needs to be constructed in such a way that it allows for release of small batches rather than one big bang release. This requires building versioned APIs and implementing patterns such as circuit breakers.
- Decouple deployment from release. Integrating feature flags into your continuous delivery pipeline. Using feature flags will allow you to decouple deployment from release so you could release some changes while keeping the ones that you don’t want to expose to users behind a flag with a simple on/off toggle. The idea is to deploy continuously but release new features on demand.
- Reduce batch size. Releasing in small batches actually reduces the risk of deployment as it becomes easier to spot and roll back accordingly.
- Optimize for resilience. Basically, teams should always be prepared in case something goes wrong and to treat each setback as a learning opportunity. Thus, it is important that everyone on the team knows what procedures to follow to locate a problem and get things up and running again.
Because you are continuously releasing your changes, you get faster feedback from your users. This way you can make adjustments as needed taking into account your customers’ feedback resulting in higher customer satisfaction with your products.
Better coordination and productivity
Continuous delivery reduces the stress associated with software release, particularly when it comes to rollbacks. Also, releasing more frequently not only helps the team work at a more efficient pace but also allows developers to actively engage with users as they are continuously monitoring any small changes they introduce to their releases. This allows them to eventually provide more value to their end-users.
The CI/CD process
The first step starts with continuous integration then continuous delivery builds on this process by performing the necessary steps to release the changes integrated into the shared trunk during continuous integration. Together, CI and CD deliver many benefits including shortening the software development process, allowing developers to receive instant feedback and features to be released frequently.
Continuous delivery is oftentimes confused with continuous deployment but there is a distinct difference between these two procedures. While continuous delivery, the software is ready for deployment but human intervention is required to trigger these deployments, with continuous deployment, you deploy the software immediately and automatically.
This means that with continuous deployment, every change automatically goes into production. Meanwhile, when it comes to continuous delivery, you have the option to release to production but you may choose not to do so. However, to implement continuous deployment, you need to do continuous delivery.
CD and DevOps
DevOps brings together the concepts of development and operations, highlighting the collaboration between the two. Thus, the DevOps culture emphasises the shared responsibility between development and operations.
CD is often linked to DevOps because part of adopting a DevOps culture is increasing value and responsiveness through quick and high quality delivery. Such an approach necessitates the creation of a continuous delivery pipeline.
In other words, DevOps provides the conditions necessary to develop, test and deploy new software and so the outcome of implementing DevOps is a CI/CD pipeline supported by effective collaboration between development and operations teams.
Continuous delivery and feature flags
Implementing continuous delivery is not without its risks and hurdles. However, using feature flags alongside continuous delivery makes it easier to maintain the momentum.
CD requires a great amount of speed. However, there are times when you find that you need to slow down to finish changes to a feature, which puts a damper on the continuous flow that you were trying to maintain, beating the whole purpose of continuous delivery.
With feature flags, though, you can maintain that momentum. If there are still incomplete changes to a feature, you can leave these changes turned off by using feature flags until it’s ready but you would still be able to proceed with the release if other changes are ready for deployment.
The benefits of using feature flags with continuous delivery are clear. No longer would you need to wait for all changes to be ready to deploy your feature which means you can still deliver your features rapidly and safely to your end-users.