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
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 problems come to light soon enough after they were created that everything is fresh in the minds of the developers;
- 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.