Continuous Integration

How many times in your career have you heard the phrase “It worked on my machine?” Or perhaps you have uttered it yourself? Until your code is integrated with the rest of the production code and passes all tests running on an approved machine (one with an environment similar to production), you don’t really know that it works. (You still don’t really know that it works, of course, until it’s sitting in front of the customer.)

The job of a continuous integration (CI) server is to monitor your source repository and kick off a consistent build process when a commit occurs. Once the build completes, the CI server notifies any interested parties and retains build output for future reference.

Your build script should compile, link, deploy, run unit tests, run any other tests, and do anything else you deem necessary to demonstrate that you could ship your system—at least to the next level. Some high-capability teams have enough confidence in the build that they have evolved one level to the notion of continuous delivery—with each successful build, software is deployed to production.

Your CI build might take a while to run, and that’s OK. The nice part about having a CI server is that you can continue to work, and you’ll know once it finds out about any problems. Be careful, though. Don’t allow the tool to let you get complacent about your overall build time. A slowly but surely increasing build process will soon become a problem. Getting feedback several times throughout the day is essential.

In a TDD shop, a CI server is a foundational tool. It makes no sense to proceed without one. The tests (including any nonunit tests) represent your best indicator of the health of your overall system. When you commit, you want to know that your code adds to the value of the system and doesn’t break anything in the latest, integrated version of the codebase.

Make sure your team is in agreement about all the processes surrounding the CI server (see the next section on standards). You should know what’s expected of you when you commit, and you should know what should happen in the event that the CI server reports a build failure.

Numerous CI servers exist. Well-known tools include Jenkins, buildbot, CruiseControl, and TeamCity. You’ll want to choose one that meshes well with your environment and your build scripts. You’ll find some good discussion on appropriate CI tools at StackOverflow.^[37]