Continuous Integration vs. Continuous Delivery: what’s the difference?
Continuous Integration and Continuous Delivery go hand in hand. In fact, more often than not you won’t see or hear one term without the other. So is there a difference? And does it even matter? Yes and yes.
Continuous Integration and Continuous Delivery defined
Continuous Integration (also known as CI) is the practice of automatically merging code into a single development branch to allow for more efficient and automated testing to occur on a regular basis as soon as code is ready. This approach enables teams to test more frequently and in smaller batches, which helps find issues faster and more easily and speeds up the overall development process.
Continuous Delivery is the process of pushing software updates to your product as soon as they are developed and tested (usually through Continuous Integration). This practice typically allows companies to release updates to their product several times a day, with the goal of getting changes in front of customers more frequently.
How are they different?
Continuous Integration and Continuous Delivery often get conflated. This happens primarily because Continuous Delivery is the natural and immediate follow-on to Continuous Integration. However, even though the two processes are very closely related, they are still quite different.
The biggest distinction between Continuous Integration and Continuous Delivery centers around the requirements and complexity for each. Specifically, testing usually only needs to happen once for each line of code, which means that teams can run Continuous Integration one time to meet their needs.
Delivery, on the other hand, is much more multifaceted: The same code (whether it’s a feature release, bug fix or anything else) might get delivered multiple times, for instance to a staging environment, to a canary system or even several times to the production environment if it has a feature flag or requires bug fixes.
Why distinguishing between Continuous Integration and Continuous Delivery matters
Continuous Integration and Continuous Delivery have very different procedures and lifecycles, but if you treat them the same, you will very quickly run into situations where they start to clash and cause processes to become incredibly slow. It can even reach the point where the old, manual way of doing things becomes faster.
Consider a case in which a new feature has gone through the Continuous Integration process, is fully tested and ready to be shipped. If Continuous Integration and Continuous Delivery are run as a part of the same process and that feature has to be delivered multiple times, then every time it needs to be re-delivered it must also go through Continuous Integration again. That adds an extra (and unnecessary!) step each time that can slow down processes and create additional opportunities for error. Ultimately, if the two are not treated independently, you can easily end up in a bad situation waiting for a previously completed test suite to finish a second go-round in order to re-run the delivery script.
Quite simply, because the delivery process has its own lifecycles, processes and procedures, it needs to be treated as a distinct element of the software development process. Doing so ensures both Continuous Integration and Continuous Delivery can operate in an efficient and automated fashion without disrupting one another.
How to effectively differentiate between Continuous Integration and Continuous Delivery
Running Continuous Integration and Continuous Delivery as a single process is like trying to drive a car by going under the hood and messing with the gears. Separating the two is what gives you the tools (a steering wheel, a gas pedal, a gear shift) to drive more easily and efficiently without upsetting the inner-workings of the machine.
Today, most organizations combine the two by simply running delivery through their Continuous Integration system. However, this is exactly what causes the problems described above.
Instead, what organizations really need is a separate system dedicated to Continuous Delivery. This system should provide easy levers for the team to do things like rolling back code or halting a release in order to offer fine grain control over the entire process. It should also provide this control in a way that’s easy and obvious for anyone to operate – much like moving from driving a car by going under the hood to driving a car via tools like a steering wheel, gas pedal and gear shift. Importantly, this separation not only provides better control over the delivery process and avoids many potential challenges, but it also helps enhance the Continuous Integration process.
Interested in learning more about the importance of introducing a dedicated system for Continuous Delivery? Contact Spaceship today to discover how we can help.