Continuous Integration isn’t a tool!

Posted by Keith McMillan

November 4, 2009 | 1 Comment

I’ve gotten into several discussions in the last few months with various people who work at my current client, and a surprising number of them think that continuous integration is a tool. The conversation usually starts when someone says something like “We’d like to be doing continuous integration, but we can’t get the server set up correctly.” It’s a this point that I have to chime in and let them know they don’t understand continuous integration.

Many people are familiar with tools like Maven and CruiseControl, and while my client is using a customized vendor product, they all do pretty much the same thing at their core: they watch to see when you check changes to your source code in to your source code control tool, then they swing into action. The tool checks all the code out and runs your build scripts. If the build fails, it notifies the developers that they’ve caused a problem.  Many teams include running a test suite as part of running the build, and if the tests fail, that means that the build has failed. Some teams even include acceptable levels of unit test coverage or other metrics as part of deciding whether the build is good or not.

Continuous integration, on the other hand, is the practice of integrating the changes from all the members of the development team on a nearly continuous basis.  This means that developers work in small increments, and typically check their changes in at least once a day, sometimes more often than that. This means that rather than waiting a week to update your workspace with all the other changes your colleagues have been checking in, and then dealing with the complex and painful process of merging their changes into yours, you retrieve their updates frequently, and share yours with them just as frequently.

This requires changing your way of working a bit: you have to focus on doing your work in small enough bites that you can check in without breaking everything, but it’s entirely doable.

So this is the substance of the misunderstanding: having a tool that builds your changes when you check in is a good thing, but it doesn’t mean that you check in very often. Conversely, it’s entirely possible to check your changes in daily, and to run your regression test suite (you have one of those, right?) without the support of any tool like CruiseControl. It is nice to have a tool as a backstop, but it’s not really necessary.

I’ll keep mentioning to my colleagues that continuous integration is a development practice, and regardless of whether you have a tool or not you can still get the benefits, but there are more of them than there are of me, and it’s going to take a while to explain it to all of them.


RSS feed | Trackback URI

1 Comment »

2011-08-24 14:38:49

[…] The sweet spot for most folks seems to be in building on a shared development server, with some sort of robust suite of tests to assure that new functionality is at least working per the tests, and that nothing that used to work was broken (subject always to the suite of tests being reasonable).  This most folks will recognize as Continuous Integration (although you should really read Continuous Integration isn’t a Tool!) […]

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.