The Disco Blog

Because it’s his bag, a few weeks back Paul Duvall pointed out that “Continuous Integration is NOT about the CI server [man]” but about the process. I happen to agree with Paul, and in fact, as I like to point out (when given the opportunity) one of the most important aspects of hip CI process is the build itself. Think about it: if you take the bells and whistles out of a CI server, all you have is a sophisticated cron job that runs a build anytime an SCM changes.

With that painfully obvious fact looming, I’m still impressed with the number of people who get excited about neat-o CI servers without having examined what it is the CI server will actually execute when something changes. If your CI server is an automated compilation engine, that’s certainly a great start, but that’s not going to save your tail anytime soon, man.

To drive home this point, man, I like to demonstrate two scenarios when I give talks on CI. In scenario one, I execute a series of steps that show that life with CI isn’t any different for a developer than life without it (on the surface, that is). I:

• check out the latest version of a project in SVN
• add a feature
• write a test to verify that feature
• run a local build that compiles, tests, inspects, and even deploys
• execute an SCM update, if there is a change, I’d keep on truckin’ and run another build
• check the modified code in along with the corresponding test (assuming everything was kosher, baby)

So far, nothing new, right? These are the steps most developers take with or without CI in place. It is always fun to show the dashboard of my flavor-of-the-day CI server, which demonstrates it found the change and also ran a build without any errors. I then attempt to show how the process of Continuous Integration saves one’s tail by executing a few hurried steps. First, let me set the tone…

There is a problem in production; customers and management are in panic mode! We’ve got to figure out the problem ASAP or else!

With the ever so mellow ambience established, I:

• check out the latest smokin’ version of a project in SVN
• add a feature
• run a local build that compiles
• quickly check the modified code and prepare to split the joint (it’s Friday night baby)
• demand that my hip code be pushed into production as soon as possible

As you can probably see, in this case, I didn’t run a full build (which ostensibly includes tests); however, thankfully, the CI server then turns out to run a full build and, presto! — a test fails, causing a flurry of emails, IMs, etc to go out indicating there’s an issue. CI saved the day! Or did it?

As it turns out, in my case, it was the copasetic test that saved the day, man. All CI did for me was to execute it (via a build process that defined a test target) when there was a change– if there wasn’t a test that actually hit the modified code (and consequently failed), chances are that the offending code would have been pushed into production as soon as possible.

Continuous Integration is all about your build, man. Before you download that hip CI server, make sure you’ve got a solid build process that does more than just compilation– and as I’ve noted before, if you want to find issues quickly, start by writing some tests. Dig it?