Continuous Integration vs Continuous Delivery vs Continuous Deployment

The word continuous is now used to describe several things in the industry: integration, delivery, deployment, experimentation, monitoring, improvement. There’s nothing wrong with that, but I want to define what I understand by the first three.

I see three degrees of continuity in the world of release engineering.

  • Continuous Integration: The easiest of the three. Set up your Jenkins (or whatever you use) to check out the source, compile and run the tests with every change or periodically. Add a dashboard or push the results via email.
  • Continuous Delivery: This doesn’t necessarily mean deploying with every change, but means being able to do it. It may not be feasible for business reasons, but the application should be releasable at any point. Sadly, in some cases, the only time the software is releasable is when it’s actually released.
  • Continuous Deployment: Deploying every time a change is made to the code base. Yes, this sounds almost impossible, and for a big number of organizations, this will never happen for a number of both internal and external constraints. However, in the words of Bruce Lee: “A goal is not always meant to be reached, it often serves simply as something to aim at”. There is a number of best practices and good habits that must be followed to be able to reach this stage of maturity, but mastering at least some of them will certainly be a step in the right direction.

One Response

  1. Continuous Integration is much more than just setting up a jenkins CI server. The underlying pricipal of Continuous Integration is integrating your code within short intervals into a single mainline. This stands in contrast to working in isolated branches, and only integrating them back rarely. Working like this usually leads to merge problems (no matter if you use git, svn or another SCM). It also prevents people from doing refactorings, because if there are, besides your own, three other branches alive, you don’t want to enjoy merging them all with your refactored one.
    Continuous Integration provides you with one single source of truth (the mainline, master or trunk, however you want to call it).
    The CI-server is really just the tip of the iceberg.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: