It's an Integration of Continuous Joy

It's a continuous integration love-fest, baby!

That may be an unfortunate choice of words, but you get the idea.

After spending too much time banging my head trying to get the ol Lego Interceptor to track objects correctly, I decided to back off and put into place another key piece of the learning that I've (purportedly) wanted to do. That is, figure out how to set up a continuous integration server.

In a previous life, the QA group was also responsible for providing builds. This was a Good Thing, as we could keep things scrupulously clean, archive the "blessed" versions of external libraries required for the build, make sure the builds we were testing came from a known code label, etc etc. (QA is a great career choice for control freaks)

And I did this gleefully.

There was only one problem. The [da dum] BUILD SERVER. As a former sys admin, I happily configured server after server after server...(dedicated servers, you see) in order to insure clean environments. Each server built for a very particular project.

Somewhat wasteful of resources (now), but this was in the late 90's. Oh, and I had a whole QA lab chock full of desktop systems to pull from when I needed a new box. And we rarely had more than 2-3 projects running at any one time.

But there were problems. Like...how do you archive the build machine?

When I started, the team often just used swappable hard drives and labeled each with the project name. This wasn't, unfortunately, duplicatable as those hard drives themselves got rather crufty and weren't documented particularly well. And if the original machine that had done the build wasn't available, it wasn't like you could just pop it into another and you were off to the races. No, these were the days of Windows NT4.0, 95, and plug-n-pray.

I remember one particularly painful experience, as I was asked to find and rebuild the source code for a video codec that had gone into production. I found the source (after much mucking about) but the hard drive assigned to the product was unbootable. Oh, and the external libraries that we needed? Nope. Needed the OLD versions to link against and did we have those? (this is when I learned to check EVERYTHING needed for the build into source control. Yes, even if it's VSS. Well, maybe.)

Nonetheless, we suffered through. I would carefully build stock NT 4 images, run sysdiff /snap to grab a snapshot, install the compilers, libraries, etc. Configure everything just right and run sysdiff /diff to grab a "diff" image. Not only did this give us all the file differences, it actually diff'ed registry entries too, so anything and everything changed in the registry could be saved.

(I later used this technique + batch build scripts for our White Room Build process with wild-happy success. A completely separate group could reproduce our gold binaries with only a base NT system and my image cd. I soo.o thought I was the cat's pajamas)

Of course, if we changed a library mid-project. Or I forgot and added something unnecessary. Or compiler setup changed. I'd have to redo the whole process. (later revs included me ghosting the system at various intervals for minimal rebuild time...but it was still a pain)

Fast foward about five years. I'm introduced to VirtualPC. And the old wheels get to turning.

"Hmm....everything's emulated. Which means you could run this image on ANY system."

And then I ran across an article on Build Machine Virtualization.

Eureka!

Now where was I...oh yeah, continuous integration. I didn't want to burn resources setting up a static CI server...I just wanted to play around with it a bit. Take it home if I was so inclined. So I fired up VirtualPC 2007, built a Windows Server 2003 image, and to make an already-too-long story short, used this guide on "How to Hook UP a VS.NET 2005 Solution with CruiseControl.NET in a Few Minutes".

And you know...it WORKED!

I was also afraid that I'd be spending days mucking about with configuration files, service ports, and IIS configs. Nope.

As a matter of fact, I didn't even have to use NAnt...(the .net version of the auto build tool, ANT.)

CruiseControl.net has built-in support for building with both the msbuild.exe tool (which allows building withOUT having the full IDE on the box...I believe this is part of the sdk) as well as the msdev method. (which is what I used in the above former-life) Just feed either one the .sln file, and they happily compile

So lessee...in a nutshell, to get Continuous Integration working with a virtual build server:

1. Download VirtualPC 2007 and install it
2. Created a new Windows Server 2003 system
   
• XP Pro would probably have worked just as well
• It took a loooooong time to patch the system running on my 1.6ghz notebook.
• I highly recommend putting the virtual machine hard disk file on a USB2 or firewire external drive if you need to use the host machine while building the CI virtual machine. A 30gig iPod with disk use enabled will do in a pinch. ;^)
  
3. Configure the CI machine as an app server. The sys admin in me wanted to do it the hard way, but the "just get 'er done" piece won out and used the "Manage Your Server" wizard. Slick. Easy. Told it I wanted ASP.NET enabled and it Just Worked.
4. Download and install Subversion (using the nifty installer)
   
5. Download and install Nunit (using the nifty installer)
6. Download and install CruiseControl.Net (using the nifty installer)
7. Create your "working directory" (in my case c:\svn\NXTTest)
   
8. Grab the ThoughtWorks.CruiseControl.MSBuild.dll and copied it to c:\svn\NXTTest
9. As I was using apache to serve subversion vs. the svn daemon (in the "few minutes" example above), I changed my config just a bit. This configuration file will check the repository for changes every 5 minutes (300 seconds), rebuild if there are any changes, and run all the unit tests.

<cruisecontrol>
<project>
<name>NXTTest</name>
<triggers>
<intervaltrigger seconds="300" buildcondition="IfModificationExists">
</intervaltrigger>
<sourcecontrol type="svn">
<trunkurl>http://mysubversionserver/svn/trunk/source/tutorials/NXTTest/</trunkurl>
<executable>C:\Program Files\Subversion\bin\svn.exe</executable>
<workingdirectory>C:\svn\NXTTest</workingdirectory>
</sourcecontrol>
<tasks>
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingdirectory>c:\svn\NXTTest</workingdirectory>
<projectfile>NXTTest.sln</projectfile>
<buildargs>/noconsolelogger /p:Configuration=Debug /v:diag</buildargs>
<targets>Build</targets>
<timeout>15</timeout>
<logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
<nunit path="C:\Program Files\NUnit 2.4\bin\nunit-console.exe">
<assemblies>
<assembly>C:\svn\NXTTest\NXTtest\bin\Debug\NXTTest.exe</assembly>
</assemblies>
</nunit>
</tasks>
</triggers>
</project>
</cruisecontrol>

Bummer...the converter I used for the XML didn't seem to manually enter spacing info. And I'm not seeing easy ways to format code snippets within blogger.

Lessee...what else. I think that about covered it.

I then launched the CruiseControl.net service from the icon on my desktop, it grabbed everything and I was off to the races.

I then fired up http://127.0.0.1/ccnet/ on said build box and lo-n-behold...beautiful build goodness!

For whatever reason the box's name wasn't resolving via wins (or whatever it's morphed into) so I had to hit the CI server via it's ip address from the host. But it worked too with the ip.



I also installed the super-noofty ccTray tool. Pointed it at the CI server's IP (ie: http://192.168.0.44/ccnet/) and it too just worked.

I'm just positively giddy!