Continuous Integration versus Continuous Delivery versus Continuous Deployment
Continuous Integration, Continuous Delivery and Continuous Deployment. These similar terms are pervasive in the field of DevOps.
But if we’re dipping our toes into this set of processes it’s helpful to know the differences between them and how they work together.
So what is Continuous Implementation (CI), Continuous Delivery (CD) and Continuous Deployment (also, confusingly, CD)?
The core principle behind of each of these concepts is creating more efficient, automated processes for a particular part of the software development and delivery pipeline.
If you want to migrate to Agile or DevOps development methods, then Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment are essentials. And even if you don’t want to do Agile? Then setting up these processes can help save time and money.
Continuous Integration
Continuous Integration is the practice of automating the build and testing of code every single time a developer commits changes to version control.
This is a practice that allows you to more easily maintain your software in a clean and complete state, spend less time managing branches and integrate changes/resolve merge conflicts. It will also help reduce your developers’ stress levels, workload, and project outlook.
Developing software without continuous integration
In any given project, there will be multiple different developers, each working on a specific feature or component.
If you have each of these developers working for weeks at a time on their own feature, then try to combine them all at once, then your main project may be full of bugs. This is because even if each of the components work perfectly independently (and with the original larger project), there may be unexpected side effects when they’re all introduced together in a big batch.
How continuous integration solves this issue
With continuous integration, each developer gets the latest version of the main project, makes a small change, then triggers the continuous delivery stage to make sure the whole project works as expected after the change.
When each developer goes through this process multiple times a day, it means that the main project is always in a correctly functioning, tested state.
Continuous Delivery
Continuous delivery is the set of processes that allow you to reliably and sustainably release new software change of all types (new features, bug fixes, etc.) by ensuring that your developers’ changes never break the main project—maintaining it in an always-deployable state.
The idea is to create an automated release pipeline (consisting of various stages of automated infrastructure creation, unit testing, platform testing, acceptance testing and deployment to staging) such that your code is always in a deployable state. Note that with continuous delivery the final deployment to production is always manual.
Toolsets such as Jenkins and Spinnaker make this process as easy as possible. They offer the functionality, all you need to do is hook up your project and workflows correctly, via infrastructure-as-code.
The process allows you to verify that your full project is in a workable, clean state, before deploying to the production environment.
Continuous Deployment
If you know that your full project is in a workable, clean state, then why not automatically send it to production?
Sure, you can do that too if you want. And that’s exactly what continuous deployment is. Rather than a human checking over the project or suggesting changes when a working product is ready to be shipped, you can just automatically do it with continuous deployment.
This doesn’t necessarily mean that you automatically deploy on every single code change, you could set continuous deployment to a daily or weekly schedule if you wish.
Of course, there are various nuances of the real-world environment that may not exist in your staging environment (no matter how rigorous your tests), so you need to manage this process.
Most Continuous Delivery toolsets also support Continuous Deployment, it’s just a matter of choosing the right one for your unique business requirements.
CI is nothing without CD
In practice, these “separate” parts of the pipeline work in symbiosis. While it’s possible to do continuous integration without continuous delivery and/or continuous deployment, it doesn’t make sense from an efficiency standpoint. And while you can do continuous delivery and/or deployment without continuous integration, this also doesn’t make sense (except, perhaps, on very smaller or less complex projects).
They function together to make deployments as boring and predictable as possible, so that it is as straightforward to release as often as the business requires. The result is faster time-to-market, higher quality product, lower costs and more relaxed, happier teams!
