CruiseControl.NET 1.4 RC1 now available.

If you are using .NET, and are doing Continuous Integration, you have probably heard of CruiseControl.NET (frequently referred to as CCNet, and not to be confused with it's original Java cousin which is just CruiseControl or CC). I have used it for several years now, often working off a locally built version so I could take advantage of unreleased enhancements. Depending on where you work, you may not have that luxury, in which case you may be interested to know that CCNet 1.4 RC1 is now available.

CCNet runs (at least in my case) on a dedicated build machine. It just sits there in the background watching for changes to the source code. Shortly after a change is observed the code is retrieved from source code control, built, unit tested, and has a few other tools such as FxCop run against it. Assuming the code meets a set of predefined criteria (code builds successfully, all unit tests run, code coverage is greater than 80%, and there are no major concerns indicated by FxCop) the build is considered a success and made available to others for additional testing (and eating our own dog food). If not, possibly because of an unforeseen interaction with other code, a build failure is signaled and work can immediately start to resolve the problem.

Before we go much further, in the interest of full disclosure I should mention that I am probably a bit biased about CCNet. I don't have code commit rights, but you may notice my name on the contributors page, and on documentation pages from time to time! With that out of the way, I guess perhaps I should get on with the main reason for writing this entry... my experience migrating from our current (1.3 locally built) version to the new one.

Getting CCNet is simple enough, you can choose to download it as an installer, a simple zip file, or a source-code snapshot. There is also a fourth item on the download page at SourceForge which is a stand-alone installer for the CCTray utility which I will talk more about later. I use the zip version because I like to keep the CCNet executables we are using under the same version control software as our source code. That way if I ever have to recreate a particular build I know that I will be using the same versions of the tools.

For me, the experience was completely painless because there have been no breaking changes between version 1.3 and 1.4 RC1. All I had to do was shut down the server (and IIS which is typically used to provide a web interface), unregister the CCNet service, copy over the new files, register the new CCNet service, then start the servers again.

The first thing I noticed about the new version (or at least the web interface) was the graphs which are now available. They provide a great way for you and/or your managers to get a quick overview of how your project is progressing over time. For example, typically you would want (and expect) the number of unit tests to increase over time, and number of FxCop warnings to stay the same or decrease. I was shocked to see that for one of my projects there had been a sudden jump in FxCop messages which occurred about a month ago, and I could quickly look back in the revision history to see what had caused the increase (a new rule had been enabled). The responsiveness of the web view has also been improved, but had never been a significant problem for our team anyway.

One long-requested feature now present in CCNet is the ability to use parameters in the configuration file. Previously if you had common configuration options you would either have to repeat the option in the CCNet configuration file, or understand enough about XML to use DTD entities. (You could also have done what I did and write a quick tool to auto-generate your CCNet configuration file, but that choice wasn't mentioned in the documentation :-)) Now, defining reusable chunks of configuration is as simple as adding an XML namespace reference and a define element or two, then referencing them with a $(entity_name) as needed. I haven't done it yet, but I'm planning to refactor my CCNet configuration file to take full advantage of this feature very soon!

Another feature which has been improved is the email notification mechanism, but I get quite enough emails every day anyway and prefer to use CCTray which provides a real-time view of the current status for one or more CCNet projects in your system tray. A very useful enhancement to CCTray, which requires a little work to enable, allows it to show what stage the build is in. Previously, that was somewhat difficult because all CCNet (and therefore CCTray) knew about was the process it had most recently launched - often NAnt or MSBuild. The new release adds a mechanism where progress information can be passed back to CCNet from any process via an XML file. Helper libraries are provided for both NAnt and MSBuild allowing them to provide the information CCNet needs to provide a richer build progress indication.

In the "just for fun" section, the latest version of CCTray can talk to you! Using the text to speech API, CCTray will announce when a build starts, and when it finishes. I suspect this may soon become annoying for the person who shares an office with me, but for now I quite like it! The X10 integration is possibly a little more useful. I have heard of a couple of teams who use X10 to control a lava lamp. A build failure turns on the lamp, and it is the team's goal to fix the build (turning the lamp off) before the first glob of goo bubbles to the top!

Hopefully if you didn't already have an automated build process in place you are now asking yourself if it is worth getting get a similar system up and running. Well there are even tools to help you do that too, and next time I hope to tell you about my experiences with Jay Flower's CI Factory