Self-Monitoring Build System…

Currently, I’m helping a client get their Continuous Integration system in a little better shape. They have CruiseControl.NET installed and monitoring their VSS repository (I know, I know, don’t get me started – I’m working on getting Subversion adopted). When spinning up a project, I’m a big advocate of having EVERYTHING under source control and that includes the build system itself. This is a brief guide on how that works.

CruiseControl Configuration

First you need to configure CC.NET for your environment so that it’s monitoring your SCM and ready to execute your build script. Here’s our ccnet.config that accomplishes this:

	
		c:\buildlogs\buildsystem\
   		c:\build\buildsystem\

http://buildserver/ccnet/

		60
		
		   C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE
		   $/Repos/BuildSystem
		   build
		   buildpw
		   true
		
		
			
				tools\nant\nant.exe
				default.build
				300
			
		
		
			
			
				
					
				
				
					
				
			
		
	

NAnt Script

This file is then checked into a project called “BuildSystem”, to match the configuration file, along with a build script that will copy the edited files over top of the existing ones and a copy of NAnt to execute it.

< ?xml version="1.0" encoding="utf-8" ?>
<project name="AffiliateIntranet" default="deploy" xmlns="http://nant.sf.net/release/0.86-beta1/nant.xsd">
  <target name="deploy">
    <copy file="ccnet.config" todir="D:\Program Files\CruiseControl.NET\server" overwrite="true" />
    <copy file="dashboard.config" todir="D:\Program Files\CruiseControl.NET\webdashboard" overwrite="true" />
  </target>
</project>

Now when changes are made to the files and checked in, the build system will see the changes and copy the new files over top of the old ones. CC.NET will see the new file and restart in order to pick up the changes. This is why we have to do it using NAnt rather than the built-in version.

Why, Why, Why

While a configuration like this may seem like overkill, it helps to cut down on the amount you need to remote to the build server as well as decreasing the amount of time to spin up a new build server should the current one decide to take a “dirt nap”.

David O’Hara is a Senior Consultant with Improving Enterprises in Dallas, Texas.