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.

Continuous Integration

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

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[1]
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.

Continuous Deployment

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.

Kind regards

Pieter Versteijnen and Harm Pauw

[1] Source: Martin Fowler website: http://martinfowler.com/bliki/ContinuousDelivery.html

Previous articleUI tests with Selenium – Docker and on-demand Grids
Next articleScrum causes more change for developers than you might think!
mm
Hi, my name is Pieter Versteijnen, married and father to two sons. At DevOn, I work as Technical Agile coach. This means that I, besides coaching teams in Agile/Scrum, also support teams on technical aspects such as setting up a Continuous Delivery pipeline. I also facilitate TFS related training courses, Test Automation courses and several Agile/Scrum foundation training courses. When I'm not working, I like to play tennis and working on, or of course riding my motorcycle. Training courses: Continuous Delivery training, Dealing with your legacy code & Continuous Delivery training, Scrum and Team Foundation Server, Automated builds with Team Foundation Server, Source control with Team Foundation Server, Work item management with Team Foundation Server, Test management withTeam Foundation Server, Scrum framework training.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*