The power of version control for maintaining a build farm

We’re practicing Continuous Integration at Ihc for about 5 years now. We started small with a few projects on one build server.

Last week we added a third CruiseControl.Net server to our modest build farm and now run about 80 build projects.

We’re proud that we maintain the configuration of this build farm with minimal effort (only a few hours of maintenance per month) and at low cost (it’s open source).

The one thing that really made things a lot more maintainable is putting the CCNet configuration in Subversion.

We basically implemented the solution from this post: http://www.ifunky.net/Blog/post/Cruise-Control-Auto-Rebuild-with-CCNetconfig-in-Source-control.aspx

And added the following:

  1. We structured the configuration into a folder per buildserver to be able to update the configuration per server.
  2. We split the one ccnet.config per server into multiple files, one per team.
  3. CCNet only reloads itself when ccnet.config is touched, so we Touch it now in the build with an Exec task.

So this makes it easy to:

  • create new projects with a simple commit
  • add a new buildserver (provide config + initial checkout on the server)
  • recover from a major buildserver crash (checkdisk removed our configs once)
  • change all configs at once with a tool like notepad++
  • move projects from one buildserver to another

This works quite well for us.

I’m wondering how easy and cheap this would all be in competing tools like TeamCity or Team Foundation Server. Any experiences you would like to share?