This article is the first in a three-part series on the use of CruiseControl.NET, a very popular and important tool for any development house interested in implementing continuous integration and other agile programming concepts. In this first installment we'll briefly cover the definition and use of continuous integration (CI), some of the other CI tools available, and the basic setup and operation of CruiseControl.NET. While these articles will cover the core elements of CruiseControl.NET, we will be covering only a small portion of its functionality and you are encouraged to read through the excellent online documentation.

So What Is Continuous Integration?
In brief, it's the process of integrating the various components of a software project on a regular and frequent basis to enable early detection of problems along component boundaries. For a much better read on the structure and benefits of continuous integration, check out this essay from Martin Fowler and Matthew Foemmel (www.martinfowler.com/articles/continuousIntegration.html).

Continuous integration is especially well suited for development teams. Most of us have had the unfortunate experience of working for several days on a key feature until it works perfectly, only to find out that it no longer works with fresh builds of the other components. If we are lucky, the failure will be obvious such as a compiler error. If we're not so lucky, it will appear to work only to fail later during release testing.

I know what you're thinking. You're thinking that all you need is a good set of integration tests and you'll just run those tests before you commit your changes. That can work, but then you'll need to run those tests for every commit because even the smallest change can break the build. Oh, and don't forget to run those tests on every .NET platform available, including Mono. And don't forget about the 64-bit variants of those platforms. You get the idea. Computers are excellent tools for doing repetitive tasks and letting us know what happened. Enter your favorite continuous integration tool, stage left.

But I'm A Single Developer
Some argue that single developers have little or no need for continuous integration. There may be some truth to that but, having worked as a single developer on a project, I can tell you that a good CI setup will speed your development process and help you catch platform errors sooner. While you are working on that next great feature, your build machine is checking out the latest commits on all supported platforms. It's like having an assistant that is constantly making sure your code works on all supported runtimes. What's better than that?

As we'll see in parts two and three, the CI build process can be extended to include all sorts of tools that help us monitor the health and quality of our code.

Ok, I Get It.
How Do I Get Started?
As with most categories of software development tools, there are several choices available. The most widely used .NET-based CI tool is CruiseControl.NET, developed by ThoughtWorks, creators of the older and also very popular Java-based CruiseControl. For the remainder of this series, any use of the term CruiseControl or CCNet will refer to the .NET product.

CruiseControl is distributed under the ThoughtWorks Open Source Software License, which is similar to the Apache and BSD licenses. The latest bits, release notes, and installation instructions can be found at http://confluence.public.thoughtworks.org/display/CCNET/Download.

Basic Setup of Cruise Control .NET
Now that we have the software, let's go through a basic setup. At this point you may want to give some thought to where your CI process will live. If you have a spare machine you might consider using it as a dedicated build machine. One of my farm machines, for example, runs CCNet and a mail server. If you do not have any spare physical machines, a good alternative is VMWare or Virtual PC. I run Windows Server 2003 as my host machine, but I almost always have one or two Virtual PC sessions running some variety of Windows or Linux.

Now that you've decided where CCNet should live, installation is as simple is running the CCNet installer. In the typical configuration you'll get a stand-alone version and a service-based version, along with a Web application that can be used to monitor the build processes. The stand-alone version, ccnet.exe, is most useful for debugging your configuration script (be sure to stop the CruiseControl.NET service first). You should use the stand-alone version while you are creating or modifying the config file since any errors will be output to the console, and because debugging is very easy and fast. Once the project is building cleanly you can move to using the service binary.

Once installed, the next step is to edit the ccnet.config file. This XML file defines the projects and their options and normally resides in the server directory inside the CCNet installation directory. Each project that you want to control should be defined using a <project> element. CCNet has many features and options, but each project boils down to three basic actions: get code, act on code, and report on the results of those actions. As you can see from the following example, each of these actions maps to an element in the config file.

<project name="Example1">
	<sourcecontrol type=""/>
	<tasks>
		..list of tasks here..
	</tasks>
	<publishers>
		..list of publishers here..
	</publishers>
</project>

We'll take each one of these sections and briefly describe its basic usage, thereby working our way to a fully functioning CCNet setup.

Starting an Integration
CCNet supports several different methods of determining when to start an integration cycle. This is done using a triggers block. Three different triggers types can be specified. An interval trigger element causes an integration to begin a specified number of seconds after the last one finishes. A schedule trigger starts integration at a specified time each day. A filter trigger specifies a set of times when integration should not start, perhaps due to backup or maintenance. Here is an example of a trigger block that launches integration five minutes after the last one ends.

<project name="Example1">
   <intervalTrigger seconds="300" buildCondition="IfModificationExists"/>
</project>

The buildCondition attribute value "IfModificationExists" indicates that the integration should only happen if CCNet has detected that source code changes have occurred. A value of "ForceBuild" will build on the given interval in any case.

Getting the Latest Bits
Therefore if CCNet has to check the source code for changes, then we need to tell it what type of source control system we are using and how to access our repository. Several types of source control are supported, including CVS, SourceSafe, Subversion, StarTeam, and many others, but for this series we'll focus on Subversion. The other source control systems will function in a similar way.

To specify the source control settings, use the sourcecontrol element. Consider the following:

<sourcecontrol type="svn">
	<trunkUrl>svn://svn.myhost.com/example1/trunk</trunkUrl>
	<workingDirectory>c:\dev\example1</workingDirectory>
	<username>myusername</username>
	<password>mypass</password>
	<tagOnSuccess>false</tagOnSuccess>
</sourcecontrol>

This fragment specifies that we are using Subversion (type = "svn") and gives the repository URL using the trunkUrl element. The code found at that repository will be checked out and placed in the directory specified with the workingDirectory element. You can use the username and password elements to specify your authentication credentials for the repository. The tagOnSuccess element is used to tag the Subversion repository after a successful integration.