There are many other options available for the subversion source control block and we'll cover some of those in parts two and three of this series. We'll also cover some special considerations when using svn+ssh style authentication.

Building the Bits
Once the source code is checked out, CCNet will run through the defined set of tasks. As with source control, a number of different task element types are available, including executable, NAnt, Visual Studio, NUnit, file merge, and many others. We'll cover the file merge, NUnit, and Visual Studio tasks in parts two and three, but for now we'll just focus on the NAnt and exec tasks. For those who might not be aware, NAnt is the .NET-based sibling of the popular Java-based build management tool Ant. It uses XML-based build files that are roughly equivalent to makefiles. The NAnt CCNet task is used to execute a NAnt build file on our source tree. Here is the part of the ccnet.config file that specifies how to run a NAnt build file as part of our project.

<nant>
	<executable>c:\program files\nant\bin\nant.exe</executable>
	<baseDirectory>c:\dev\example1</baseDirectory>
	<buildArgs></buildArgs>
	<buildFile>example1.build</buildFile>
	<targetList>
		<target>go</target>
	</targetList>
	<buildTimeoutSeconds>1800</buildTimeoutSeconds>
</nant>

The parts to understand about this fragment are the buildFile, targetList, and buildTimeoutSeconds elements. The buildFile element specifies the name of the NAnt build file to use. Note that in this example we don't include any path information with the build file so it expects to find the file in the baseDirectory path. The targetList element specifies the list and the order of targets that will be built during this execution. Just as in a makefile target, a NAnt target specifies how source code gets turned into output files. For more information on NAnt and its usage, please see http://nant.sourceforge.net/. The buildTimeoutSeconds element speci-fies how many seconds CCNet will allow the NAnt task to exe-cute before it terminates it. This prevents a hung task from bringing the entire build process to a halt.

For those situations where we don't want to use NAnt, we can use the exec task. Perhaps we have an existing project that builds from a makefile. Rather than convert the project to using NAnt, use the exec task to execute NMake and process the existing makefile. Here's how it might look:

<tasks>
	<exec>
		<executable>nmake</executable>
		<baseDirectory>c:\dev\example1</baseDirectory>
		<buildArgs>all</buildArgs>
		<buildTimeoutSeconds>60</buildTimeoutSeconds>
	</exec>
</tasks>

What Happened?
No matter what tasks you use in your CI setup, it's important to find out the results of those tasks. This is handled using the publisher tasks. The important thing to remember is that the Web dashboard uses an XML-based log file to report results so every project should include an Xml Log Publisher task. This is defined using the xmllogger element as in the following example:

<publishers>
    <xmllogger logDir="c:\dev\example1\logs"/>
</publishers>

The Xml Log Publisher is so important to the publishing aspect of CCNet that if you don't specify one, the Web dashboard will not function correctly, so you should always include this in your project. You don't have to specify a logDir for your Xml Log Publisher. If you don't, the logs will be saved under the CCNet install directory.

The Web Dashboard
The Web dashboard is a simple Web application that can be used to monitor build status and progress via a Web browser. By default it gets installed under the CCNet virtual directory, so if your build machine were named "builder," you could open your browser to http://builder/ccnet and view the status of your CCNet projects. You can also view the logs for the projects and force rebuilds.

Getting Notified
CCTray is a handy little tool that allows us to keep tabs on our projects without having to keep the Web dashboard loaded into a browser. CCTray is a .NET app that sits in your system tray and monitors one or more CCNet installations and lets your know the current status by changing the color of the CCTray icon along with optional audible cues. You should note that CCTray is a separate download from the main CCNet installer and it should be installed on any machine from which you want to monitor your projects.

Our Setup
There's a great simplicity that comes from having a separate build machine that is constantly monitoring a source repository, checking out the latest bits, compiling them on every runtime, and executing a set of unit and regression tests. Here at MySQL, we use CruiseControl for our Java work and CruiseControl.NET for our .NET work. Each team is working to integrate the output of our various build tools into the CI build log, not only for our benefit, but to include in our project packages as well. By using CruiseControl we can not only publish the build success or failure of each project, but other data points as well such as unit test success or failure, code metrics, coverage analysis, coding rule analysis (i.e., FxCop), performance and profiling data, and others.

Looking Forward
In this first part we have taken a look at a basic CruiseControl.NET setup that makes use of NAnt and Subversion. In the next install-ment, we'll focus on integrating tools such as FxCop and NCover into our CCNet setup. In the final installment, we'll look at extending our CI setup to include Linux and Mono.