published on: mingster

In a Team development environment where parallel development and testing goes we find a requirement of getting most recent build to test as well as some specific build to give the QA to do testing on. This post describes what all are needed to set up an automated source code integration and build system for an environment where we use Visual Studio for development, source control (SVN in our case) for source depot, and doc/ tracking system (trac in our case).

Why do we need a continuous source code integration and build system? well, this helps the QA team by allowing then to not spend more time in syncing the source and doing a build everytimes or even working on a relatively older build.  This works as a perfect backup for your Source Control and also the deployment server. This also allows to align the builds numbers to be same as your assembly\file version and also to the source control label there by making a particular build to be a complete unit in itself in terms of readiness for deployment or using the same for development.

Now coming back to build server where we can use cruise control .NET for source integration along with a couple of batch scripts to control the build number and assembly version. CCNET pings the source control (SVN) after every 30 mins (this is a default value and can be changed) to see if there are any modifications. If there are then it triggers a build and publishes it on the Build Server. Once done sleeps again for 30 mins unless it is Forced for a build in between i.e. you can manually force a build in between sleeps.

The core components of build server are:

1) Cruise Control .NET (CCNET):
Its an open source build and integration engine which can be downloaded freely from http://confluence.public.thoughtworks.org/display/CCNET/DownloadOnce. Once the installation is done CCNET needs to be configured according to your requirements.  The config file can be found at “%SYSTEMDRIVE%\Program Files\CruiseControl.NET\Server\ccnet.config”.

2) Batch Scripts:
You might have some tasks to do before the automated build.  In our case, we want to shift the version in every new build. It can be done by altering AssemblyVersion attribute defined in AsseblyInfo.cs file(s). Also you might need to get all the green lights in NUnit testings before you build.  CCNET integrates with NUnit & NAnt nicely for executing test cases and more powerful automated scripts.

Fpr complete reference on the configuration blocks, check out the project home at http://ccnet.sourceforge.net/CCNET/.  If you like to do the same on Linux, you might wanna check out luntbuild