Intro to Continuous Integration, Continuous Delivery, and Continuous Deployment
What is CI/CD/CD? The Differences & Benefits & DevOps Application
In the DevOps world, the terms continuous integration, continuous delivery, and continuous deployment are quite common. What’s also quite common is that these terms are used interchangeably, often as synonyms.
This is a mistake. Even though all of them are part of the software delivery process, each has its own requirements, and more importantly, benefits. And understanding these differences is the first step in properly implementing them.
But what are the differences and how do the different approaches fit into the development process.
Table of Contents:
- What is Continuous Integration (CI) & Benefits?
- What is Continuous Delivery (CD) & Benefits?
- What is Continuous Deployment (CD) & Benefits?
- Continuous Integration vs Continuous Delivery
- Continuous Integration vs Continuous Deployment
- Continuous Delivery vs Continuous Deployment
- The Pitfalls of Only Focusing on Continuous Integration
What is the Difference Between CI/CD/CD
As stated, these three approaches all differ in their implementation and what they mean to a development team. Think of it basically as a timeline. At the beginning, there’s continuous integration and then continuous delivery or deployment follows.
They take place in this order with continuous integration being the foundation the others need. In other words, it’s simply not good practice to implement continuous delivery without properly implementing continuous integration first.
So, with that in mind, let’s look at the differences.
Continuous Integration (CI)
Continuous Integration is the practice where developers merge the changes to the code base to the main branch as often as possible. These changes are validated by creating a build and then running automated tests against the build. If these tests don’t pass, the changes aren’t merged, and developers avoid integration challenges that can happen.
Benefits of Continuous Integration
This process also causes fewer bugs to be shipped to production as the issues are caught early and integration issues are solved before release.
Continuous Delivery (CD)
Continuous Delivery is an extension of CI since it enables automation to deploy all the code changes to an environment (dev, qa, stage, prod, etc.) after the changes have been merged. The artifact may be built as part of CI or as part of this process since the source of truth (your repository) is reliable given your CI process. In simple terms, this means that there is an automated release process on top of the automated testing process and that developers can deploy their changes at any time by simply clicking a button or at the completion of CI.
Benefits of Continuous Delivery
Since developers can deploy their changes at any time, it’s recommended to deploy the changes to production as often as possible, making troubleshooting easier and providing your users with access to the best your product has to offer as soon as possible. Often times, the release to production may be managed by a Release Manager and governed by a compliance process to ensure organizational processes are being met. By enabling non-technical team members to control this process, you can reduce the burden on the development team so they may continue to execute on further application improvements.
Continuous Deployment (CD)
Continuous Deployment takes the process one step further than continuous delivery. Here, all changes that pass the verification steps at each stage in the pipeline are released to production. This process is completely automated and only a failed verification step will prevent pushing the changes to production.
Benefits of Continuous Deployment
Apart from the fact that customers get updates quicker, developers also get feedback faster which means there is less pressure as small changes are pushed incrementally compared to big updates not that often. In order to successfully accomplish Continuous Deployment, tracking metrics around Mean Time to Repair and Change Failure Rate is critical to the success of fully automated deployments.
Now, that we’ve recapped what these all mean, let’s look at the specific difference, which to some extent may already be apparent.
Continuous Integration vs Continuous Delivery
As appears from the description above, continuous integration is simply the process of integrating changes made to the code into a mainline code base. For this, developers use platform specifically designed for this purpose.
In contrast, Continuous Delivery is the processes that happen after the changes have been integrated in the code base to bring these changes to customers. So, as stated, the difference between CI and CD isn’t as much a case that they’re two different approaches, but rather two complimenting approaches.
It usually involves testing, staging, and deploying code. Continuous Integration has been around for much longer and specific CI tools exist to solve these problems. Leveraging a Continuous Delivery tool, instead of forcing a CD pipeline into your CI tool has the same benefits of using a hammer for a nail and a screwdriver for a screw – the right tool for the right job.
Continuous Integration vs Continuous Deployment
The differences between continuous integration and continuous deployment are largely similar to the difference mentioned above. The further difference is that continuous deployment deploys changes to the customers automatically without any human intervention.
Continuous Delivery vs Continuous Deployment
By this time, the difference here is obvious. Continuous delivery is a partly manual process where developers can deploy any changes to customers by simply clicking a button, while continuous deployment emphasizes automating the entire the process.
The Pitfalls of Only Focusing on Continuous Integration
So, why is this difference important? It’s simply because many organizations and development teams conflate the two with the effect that they focus on continuous integration only, thinking that they’re also practicing continuous delivery. Or they confuse continuous delivery with continuous deployment and because they’re not ready for the latter, neglect it altogether.
Setting up a continuous integration server that merge and integrate code changes continuously doesn’t mean that a development team is practicing continuous delivery. It simply means that they’re using a continuous integration server. For example, a team could set up a server and push changes to the server to be merged a few times a day, but fail to deploy those changes continuously. Sure, this is vital to ensure less troubleshooting, but it still isn’t continuous delivery.
To properly implement continuous delivery, the team has to set up their software testing, staging, and deployment processes in such a way that most of it is automated and takes place continuously. This means they have to use the right tool for the job and not try to make their continuous integration tool do the job it wasn’t supposed to do.
This conflation of the two methodologies also brings about several distinct disadvantages. Here, the team who mistakenly believe they’re implementing continuous delivery:
- Will find that much of the complexity of deploying software will still remain and they’ll still spend days preparing for a release. In contrast, if they’re properly implementing continuous development, the complexity is largely eliminated.
- Won’t release software more often and won’t speed up the feedback loop with their customers. This is one of the main benefits of implementing continuous delivery.
- Will have much more pressure on decisions for small changes and will be prevented from iterating faster.
From this it’s clear that continuous integration is a must. In fact, development teams can’t even begin to think about implementing continuous delivery before they’ve implemented continuous integration.
On the other hand, continuous delivery is just as important, if not more so. The simple fact is, failing to implement continuous delivery significantly reduces reliability and stability. So, it’s essential to understand the differences between the two in order to make sure that both are properly implemented.