Build Pattern: Amnesiac CI Build

I first set up a CruiseControl build in 2004. It needed to get the latest version of the code onto the working area of the project. I settled on using our version control system (at the time Perforce) to update the working copy from the Ant build. You need to know things about the VCS to do the checkout. So you might as well go tag the build from the same place because you went to the effort of telling the build where to find your VCS.

Then one day, somebody realised what an incredible pain in the backside that was and invented the bootstrappers. Those marvelous bootstrappers go a long way towards fixing the problem.

What is the problem? Duplication. You need to tell your CI server where to look for changes. And you still need to tell your build some of the same facts about the VCS that you need to tell your CI server. That’s still a little bit annoying.

So bootstrappers helped no end. But there is still the thorny issue of tagging. Wherever I can I try and use a publisher to do the tagging so that the main build can ignore things like VCS info. But there’s something better now. The current batch of CI tools take things a step further and offer tagging of your VCS as something that happens to a project if it completes successfully. Which ones? I know of Team City, CruiseControl.NET and maybe Hudson.

So by pushing tagging to your CI server, your build doesn’t need to know a thing about where it really resides, or what it’s history is. So to my mind, that’s the Amnesiac Build.

%d bloggers like this: