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 (this post)
   
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
8. Part 8: Configuring CruiseControl.NET
9. Part 9: Conclusion

I've covered some of the basics of setting up a continuous integration system thus far: how I set up my development project folders and the general workflow of my CI environment. Now, I'd like to start getting the CI server setup with a run through what I consider baseline software for a build server.

Core Components

In order of installation, here are the "core" pieces of software installed on my CI build server (which runs Windows Server 2003). I consider these core because they're really the absolute minimum you can get by with in a CI environment.

Visual SVN Server / Tortoise SVN 

See my post on installing Visual SVN/TortoiseSVN.

CruiseControl.NET 

CC.NET is, of course, the core of many CI environments. It's the CI workflow engine, coordinating and firing off the necessary events to build source, run unit tests, etc. I'll delve into configuring CC.NET in my next post in this series.

CruiseControl.NET Add-ons

CC.NET has an extensible plug-in architecture. I have leaned on others' work for plug-in's to retrieve source from TFS or VSS, and have written my own to handle version updating (check out assemblyinfo.cs, update assembly version, check-in). I'll detail each of these as part of configuring CruiseControl.NET.

Visual Studio (VS2008 + VS2008SP1)

Why do I install Visual Studio on my build machine?

There's really two reasons for this:

1. There was a time when MSBuild (which comes with .NET; look in "\Windows\Microsoft.NET\Framework\v3.5") would not build setup (.vdproj) projects. Unless this has changed, Visual Studio is required to build setup projects.
2. I sometimes have to load up a project and do a build as I would on my development machine, sometimes just for sanity's sake. While I don't do development tasks on my build machine, having Visual Studio on there is a huge timesaver when things get a little screwy.

If you're using TFS for source control (like we do at my place of employment), you'll also want the TFS Explorer component. One nice thing about TFS and SVN is that they seem to play well with each other, or at least they stay out of each other's way.

Silverlight 3 Tools for Visual Studio 2008 SP1

If you're going to build Silverlight projects, you probably want the latest Silverlight Tools for Visual Studio. The alternative is having to pull dll's from the default install folder and putting them into a project or solution specific imports folder.

CI Utilities

These are key pieces of software, not necessarily 'core', but very nearly as important because of the functionality they provide. Any good CI environment isn't complete without at least some of them.

NUnit 

NCover

I use the free version that comes with TestDriven.NET.

FxCop

TestDriven.NET

Not necessary for CI, but helps with debugging unit tests (which, as stated above under Visual Studio, is sometimes a necessity or at least a timesaver).

7-zip

My command-line zip utility of choice. 

Optional Utilities

Beyond Compare

Sometimes you need to compare two files or a set of directories. This is one of the best comparison tools out there.

Conclusion

Those are the components and utilities I use as a baseline on my CI server. Next couple of posts I'll take a look at some custom CC.NET plug-in's I use as part of my CI process.