Continuous Integration: First Principles

2016-05-10

Continuous Integration is a term used by a great many software development organizations, with a very broad spectrum of possible meanings. It's hard to imagine more that about 20% of the people who claim they know what Continuous Integration is have actually ever read any articles about it to make sure they're not just guessing. In some organizations I've been in, Continuous Integration was defined as having a nightly build and heaping scorn on whoever makes it break. That's certainly better than not having an official build that often, since it implied that there is a periodic build that is:

• Done on a separate, controlled system that has known tool sets on it and
• Run strictly from what is checked in to Version Control

Those are the first principles of Continuous Integration, and practicing them is good even if it's not really the whole enchilada. However, it's not Continuous Integration, any more than acceptance to the University of your choice is a diploma. 

The next principle that some places accept is to do these builds often, even several times a day. There are projects where there is not very much activity, and nightly is often enough, but if there will be a dozen checkins picked up in a single build, it can make it a lot harder to pinpoint the cause of a failure. 

However, the next principle that a lot less projects have in place is testing the new builds. You should have unit tests, ones that developers can run before they check in, and that should be part of the Continuous Integration build too; those should be written so they run fast and report clearly, so they encourage developers to use them and they don't slow down the CI build. However, you should also have some deeper, more broad ranging tests to run after the CI build was successful and passed all its unit tests. Once you have that, you have the real deal, Continuous Integration. So our list of First Principles of Continuous Integration now adds:

• Run the builds often enough that only a few changes are picked up in each build.
• Unit tests must pass 100%
• Once that's accomplished, some function and integration tests should be run, and the build is only good if they also pass.

The reason Continuous Integration is so good that it's become as popular as it has is this: every project is going to have some developers who understand some parts of the design a little bit differently than the others, and when they code according to their idea of the design, errors can crop up that were very hard to expect. If you have enough testing soon enough, you get two advantages:

1. The problems come to light soon enough after they were created that everything is fresh in the minds of the developers;
2. and the design misunderstanding may be clear enough that the perpetrator of the problem gets a new, better understanding of that part of the design.

Back in the bad old days, we didn't have this to keep errors from being overlooked until the end of a project, and as a result 80% of all projects were tragic failures. Don't miss the opportunity to improve those odds to the moderns level - it's not as hard to do as trying to fix bugs weeks after they've been buried under layers of dependent code.