Continuous Integration vs Continuous Delivery vs Continuous Deployment

04 August, 2015 · 1 minute to read · written by Rob Gregory

Continuous Integration vs Continuous Delivery vs Continuous DeploymentWhen it comes to buzz words 'Continuous' is the word of the moment, but what exactly does continuous mean when it comes to delivering software?

In this post I describe the three concepts: Continuous Integration, Continuous Delivery and Continuous Deployment. I'll look at the differences between them and talk about how they interact with each other in the real world.

Implementing a fully continuous development / delivery workflow isn't straight forward however once setup the benefits are obvious.

Continuous Integration

Continuous Integration is the practice of constantly merging development code into a trunk/branch in source control so that checks can be made to make sure new changes work with other changes. The key concept is to test code changes as early as possible to catch any issues as quickly as possible.  Finding an issue quickly reduces the time required to resolve the issue and also reduces the risk of the unfixed issue camouflaging other issues.

Most checks are done via automated tests / builds run by a a build server allowing developers to continue working while integration testing is done. Notifications can be set up to notify developers and others about failed tests or builds.

Continuous Delivery

Continuous Delivery is the method of continuously delivering code changes to an environment such as staging, UAT or even production. While Continuous Integration allows easy unit testing Continuous Delivery deploys code changes to an environment allowing for further testing such as design or UI tests to be run. these cannot easily be done by unit testing. As with CI, Continuous Delivery allows issues to be identified quickly so that they can be fixed before the developer moves on to new tasks.

Continuous Deployment

Continuous Deployment is the deployment of code to production as soon as it is ready rather than batching together with other changes and released together. Any testing required is done before prior to merging into the production trunk.

Bringing them together

In an ideal workflow code can be checked in and automatically checked by a Continuous Integration server, Continuously Deployed to a staging environment for further tests and then once confirmed checked into the production trunk and be automatically deployed to the production environment via Continuous Deployment.

In summary 'Continuous' is about joining-the-dots between development and production ensuring rigorous testing practices are implemented along the way. The key is to employ as much automation as possible, of course this requires plenty of testing in itself but this upfront cost will pay dividends later. There are many tools and integrations out there which can help development and operations teams implement their continuous workflow. I aim to cover these in future posts.