Continuous Integration, Delivery, Deployment: What's the difference?

This time, CI/CD, or Continuous Integration and Continuous Delivery/Continuous Deployment, build well on top of each other. All three lie at the very heart of what DevOps tries to achieve. So it’s about time we get behind the abbreviations.

What is Continuous Integration?

The first step to take is CI, which stands for Continuous Integration.

In Continuous Integration, whenever a code change is made and declared ready by the developer, it is committed to a remote repository. At that point, the new changed code in its entirety goes through a set of automated tests on a server. These tests, which include regression tests, make sure no functionality was lost as new functionality was added or improved.

Best practise however, is gated commits. This means that an individual’s newly committed code is actually tested before it’s shared with other developers or testers. This encourages small changes that are merged frequently. Changes are thus straightforward and the state of the software is continuously improving because the new code is being tested.

To quote a thesis by someone at Eficode: “Continuous Integration was developed to counter the problems of [a] sequential software development model. After the requirements, analysis, design and implementation stages were finished, substantial problems were often met at the integration stage of software project.” (page 11)

In summary, Continuous Integration means contributing your new code frequently, and nowadays, in most cases, this triggers automated tests. According to most people, is a prerequisite for CD, or Continuous Delivery.

CI is hence earlier in the process to Continuous Delivery and Continuous Deployment, which we will get to next.

What’s the difference between Continuous Delivery and Continuous Deployment?

CD can mean Continuous Deployment or Continuous Delivery. There is only one small difference between the two DevOps approaches and that sits in the last phase.

Deployment is usually defined as bringing the application to a specific environment. This is usually the production environment accessed by users.

If the application runs on a website or is managed by a centralized IT-department, users have no choice but to use it. Still, a deployment can contain features users are unaware of (known as a “dark launch”), that are being tested for a future release. As that word itself suggests, a release is publicly informed about. In the case of downloadable software, a release is also more or less a choice of the user whether to test it out or not.

In Continuous Delivery, the application is delivered through acceptance tests in an isolated (test) environment to a stage where the production deployment is only a push of a button away. Usually, this button push is behind a strategic decision from management.

Or as Eficode’s Severi Haverila put it in his thesis: “...the key principle of continuous delivery is keeping the software continuously in a deployable state.” (page 11)

Continuous Deployment (or automated deployment) is automatic all the way to end user exposure. The technical setup work for both CDs is therefore practically the same: automating the complete deployment process and making the last phase manually controllable if Continuous Delivery is the intention.

The debate continues!

As with all definitions (including the definition of DevOps itself), there is debate about which definition is definitive.

Leading tool providers such as Atlassian and Puppet, seem to have come to somewhat of a similar understanding of CI/CD, analogous to the one presented earlier in this text.

Whether it can be considered a de-facto definition is perhaps too early to say. As with all other widely-used terms, they always need to be presented with a proper definition for the specific use case at hand.

Meanwhile, students of the future will have to deal with abbreviations still in the making. The whole industry nonetheless seems to agree that CI/CD, or more generally automation, is what brings developers and operations closer together.

That in the end should make the developed software generate value in less time.