Build Automation System using Cruise Control .NET (CCNET)

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, Some source control (VSS, Vault Gear etc) for source depot.

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 everytime or even working on a relatively older build. This works as a perfect backup for your Source Control and also your deployment server build. 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 (VSS or Vault etc) 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.

Let me explain the two components of build server in details below:

1) Cruise Control .NET:
Its an open source build and integration engine which can be downloaded freely from http://confluence.public.thoughtworks.org/display/CCNET/DownloadOnce installation is done CCNET (CruiseControl.NET) needs to be configured according to your requirements. the config file can be found at "%SYSTEMDRIVE%\Program Files\CruiseControl.NET\Server\ccnet.config".
A Sample configuration looks like below (using Sample Project and Source Gear Vault as source control provider):





2) Batch Scripts (Same Build and Assembly Version):
There are two batch scripts used to control the assembly version. For any executable or dll assembly version is generated based on AssemblyVersion attribute defined in AsseblyInfo.cs file. In order to have same Label and assembly version we can use batch script to change the attribute at runtime and then revert the same at the end of build process again during runtime.

Once the source integration is done by CCNET and is ready for build we change the file attributes of AssemblyInfo files (more in case of multi project solution) to -R so that AssemblyVersion attribute can be changed to build label thereby making the version of generated dll's and exe's with the same version. Now to revert back we use another script which changes the AssemblyVersion attribute back to 1.0.0.0 and change the file attribute back to +R there by dodging the source control to not treat this as a modification otherwise it will consider this as a modification and trigger the build again and go to an infinite loop of build :)

For mutli project systems where you need many assemblyinfo files to be changed you can use some utilities like replace.exe http://www.bestcode.com/assets/downloads/replace/replace.exe
Below is an example of how a batch script would look like:
#Test1.bat
attrib /S -R AssemblyInfo.cs replace.exe -find "1.0.0.0" -replace "%CCNetLabel%" -fname AssemblyInfo.cs

Complete reference on the configuration blocks can be found at http://ccnet.sourceforge.net/CCNET/ One of the useful publisher which is missing in the above config is Email publisher where-in you can send mails for build success\failure to single\set of people. This help in tracking the build failures and also QA team notification in case of build succeeds.

This can very well be integrated with NUnit for executing test cases ones the build succeeds. This post doesnt cover this though more information on this can be found at CCNET link provided above.

There is a UI support too for CCNET to control the build trigger and view build results\logs. it can be found at http://[BuildServer]/ccnet . The web dashboard for ccnet looks like:



Hope this post will help in case you are planning to set up an automated build and integration system or you are looking for a solution to have same build and assembly version for you current systems builds.

bye for now.