After attending a conference, we came to the conclusion that there are a lot of people interpreting Continuous Integration, Continuous Delivery and Continuous Deployment differently. That’s why we wrote this blog to make clear what the difference is and what the benefits are when taking the next step.
Initially, Continuous Integration (CI) originated from XP practices. But, as time has moved forward companies are using CI, but not all XP practices anymore.
We would like to start with explaining CI . So what does it mean, when are you really practicing CI?
CI is focused on integration of code and validation of the code on unit test and maybe integration test level. Your application is available in test.
To achieve this, Continuous Integration includes:
- developers check-in their code at least once a day
- code is built at every check-in
- code is automatically unit tested at every check-in
- everyone has access to the build and test reports
- the build is fast, so developers get feedback fast
- tests are executed on a scaled down version of the production environment
- deliverables are stored in a version controlled artifact repository
- deliverables are automatically deployed to a test environment after a successful build
If you have all this in place you are at a mature CI level and are able to take the next step to Continuous Delivery.
Continuous Delivery (CD) it is the next step after CI. To get this in place you should do the following:
- Your software is deployable throughout its lifecycle
- Your team prioritizes keeping the software deployable over working on new features
- Everybody gets fast, automated feedback on the production readiness of their systems every time somebody makes a change to them
- You perform push-button deployments of any version of the software to any environment on demand
- There is a close, collaborative working relationship between everyone involved in delivery (often referred to as a “DevOps culture”).
- Extensive automation of all possible parts of the delivery process has happened, usually using a Deployment Pipeline
So what is the actual difference between CD and CI?
To be able to deploy to production within a blink of an eye more is needed. Automation is the common part here. Taking the next step is to automate even more. Automate the regression test set so you are able to validate if the product is working properly without any manual testing. Beside that also automate the deployment of the application to production.
The step to production is a call the business has to make. But when they make the decision it doesn’t take a lot of time and doesn’t cause a lot of stress. It will be the push of a button to put the increment in production.
What are the benefits on top of Continuous Integration?
Reducing the risk of a deployment to production. Because (almost) everything is automated (like tests, deployment, environment setup and deployment), the risk of anything going wrong is very small
Progress of the development team is transparent. When the application is fully tested and deployed to production(-like) environment it is clear that it is really done. This way developers can’t say it is almost done and then need a week to deploy it to production.
Final and most important one is that you get feedback fast. The risk of an idea that is not working for your customers is reduced because you can get feedback fast instead of months or years later.
When you reached the Continuous Delivery level you are able to step it up a little bit further.
Final step is Continuous Deployment (CD). The same abbreviation as Continuous Delivery and that’s maybe also why many people think of this as the same thing. But there is a slight difference between these two.
When you are doing Continuous Delivery you determine when you really go to production. For Continuous Deployment you don’t. Every successful build will result in an automated deployment to production.
So in both situation you can easily deploy to production but in case of Continuous Delivery it is a choice.
Benefits on top of Continuous Deployment
- Every change goes to production directly. So the chance of missing a window of opportunity is very small.
- Feedback is returned even faster.
- By using feature toggles it is possible to deploy to production without using the new functionality. So parts that aren’t finished yet are already deployed to production. This way feedback about the deployment of that new part is received.
- Besides that it is also possible to let a small group of users test the new functionality again to receive fast feedback.
Hopefully this blog helps you to clarify the differences between Continuous Integration, Continuous Delivery and Continuous Deployment.
Pieter Versteijnen and Harm Pauw
 Source: Martin Fowler website: http://martinfowler.com/bliki/ContinuousDelivery.html