This is the next part in an ongoing series about setting up a continuous integration system. The series includes:

1. Part 1: Introduction
2. Part 2: Project Folders
3. Part 3: CI Workflow
4. Part 4: CI Server Baseline Software
5. Part 5: CruiseControl.NET Custom Plug-in: Update Version
6. Part 6: CruiseControl.NET Custom Plug-in: Source Retrieval
7. Part 7: Installing CruiseControl.NET and Custom Plug-ins (this post)
8. Part 8: Configuring CruiseControl.NET
9. Part 9: Conclusion

The first four posts of this series were mostly talking in abstractions, defining my project folder structure, continuous integration workflow, and naming the software I consider crucial to any CI environment. In the last two posts I made a side-trip, defining how to write CruiseControl.NET plug-ins. That was nice because it allowed us to jump back into some code. Now, though, let's get back to the CI server itself and define the steps I take to baseline the machine and get CC.NET ready to go.

Choose your OS

I use Windows Server 2003 as my build server's OS, but that's only because the machine does double-duty as a DHCP server, internet gateway, DNS server, and domain controller. But there's nothing to keep you from using Windows XP or Windows 7 as your build server.

Install CruiseControl.NET

The first step is, of course, to download and install CruiseControl.NET. I use the default install options.

Install CruiseControl.NET Plug-ins and Add-ons

See Posts 5 and 6 of this series for more info on CC.NET plug-ins.

1. Rodemeyer.MsBuildToCCnet.dll

If you're going to use MSBuild to compile projects, you might want this CruiseControl.NET logger add-on. The reasons are listed on the add-on's cc.net web page; I'll leave it to you to determine if this is something you need, but I've found it to be a big help in formatting MSBuild's output. See the cc.net web page for instructions on how to install.

2. ccnet.svnupdver.plugin.dll

There are a varying philosophies on how to go about updating assembly versions as part of the CI process. My preferred method is to check-out the AssemblyVersion.cs file, update the assembly version using the CC.NET build version, then check the file back in. That's what this custom plug-in does.

The ccnet.svnupdver.plugin.dll can be downloaded from posts 5 or 6 of this series (the .zip contains both the get and update version plug-ins for SVN and TFS). To install, copy the DLL into the CC.NET 'server' folder.

3. ccnet.svnget.plugin.dll

Sure, you can use one of the provided Source Control Blocks, or you can write your own. Better yet, you can use this one. The SVNGet plug-in is a custom CC.NET plug-in written by yours truly. It provides source control access to an SVN repository of your choice.

The reason I wrote this plug-in is this: As a Subversion user I was, at first, perfectly happy using the default Subversion Source Control Block. Until I ran into the update version, circular build loop which I've probably discussed to death at this point. See previous two posts for more information.

The ccnet.svnget.plugin.dll can be downloaded from posts 5 or 6 of this series (the .zip contains both the get and update version plug-ins for SVN and TFS). Simply copy into your 'server' folder and add the task block to your ccnet.config file (more on that next post).

Additional Software

You can pick and choose from what I listed as CI server baseline software, but, minimally, after what's listed above I always install the following:

1.) Visual Studio

2.) NUnit

3.) TestDriven.NET

4.) 7-zip

Conclusion and Next Steps

Installing the above software should get you a baseline CI machine, ready to go except for the configuration step. For CC.NET, that involves working with the ccnet.config file. Next post, I'll break down the various blocks and show how to add a basic project. Until then.