Continuous delivery, similar to continuous integration and continuous deployment, is a software delivery process centered around improving the speed with which development teams release new features to end users. But what is continuous delivery exactly, and how is it different from the other two continuous release processes?
We’ll discuss continuous integration first, since it’s more disparate than the other two, it’s simpler to implement, and it frequently serves as the foundation for the others. Where continuous delivery and deployment are both software release processes, continuous integration is a software development process: it happens before the deployment process.
Development teams usually implement continuous integration because of the problems which arise from long-lived feature branches; if they only pull and push to trunk once in a while, it may turn out that one developer has changed the name of a function in his feature that the other developer needs for hers. The technical term for what happens when these two developers both merge their new code to trunk is, aptly, “merge hell”.
Continuous integration is the process of avoiding merge hell by continuously merging every code change to trunk (or “master” in Git). By doing this, developers get used to the process of keeping the trunk code clean while simultaneously pushing to it regularly, and this opens the door to continuous delivery.
The central idea behind continuous delivery (and therefore also continuous deployment) is that of being able to release the current version of the software directly to the production environment and to end users at any time. The continuous delivery process has two main prerequisites: first, everyone involved in delivery must work closely together – this is frequently called implementing DevOps practices – and second, as much of the delivery process as possible must be automated – this is called a continuous delivery pipeline (or CD pipeline).
Continuous delivery vs. continuous deployment
Continuous integration is not technically required for continuous delivery, though they go together often enough that there’s a single acronym for development teams that do both: CI/CD. By contrast, continuous delivery is required for continuous deployment. This is because where in continuous delivery you could push to production at any time, in continuous deployment you do.
Continuous delivery and continuous deployment have different sets of benefits and drawbacks. The benefits of continuous delivery include the potential for more frequent releases, less deployment risk, and more transparency of development practices and progress (if something is deployed into the real production environment, or even a staging environment cloned from it, that makes it seem more “done” than if a developer just said it was finished). The main drawback is that, because there is a stage of manual quality assurance (QA) testing before changes can be deployed to users, code can get hung up in those unit tests and not proceed as quickly through the deployment pipeline as in continuous deployment, where automated testing is the only safeguard between the new code and the end users.
Implementing continuous delivery
Because code has to be production-ready at all times, that doesn’t leave developers a lot of room for error. In order to mitigate this problem, there are several commonly-implemented solutions to help development and DevOps teams provide higher quality releases.
The first is containerizing, a software development practice that involves isolating and self-containing code to make it easier to break up a large development project into smaller pieces. These pieces can then be worked on by small agile teams and released synchronously. Some open source containerization technology vendors include Docker and Kubernetes. The second solution is open source automation servers such as Jenkins, which automate continuous integration, delivery, and deployment pipelines. And the third is feature flags like Split, which allow developers to hide unfinished or broken features behind toggles and push to production with them toggled off.