Home > .NET, Continuous Integration, Test Driven Development > CruiseControl.NET – second impressions …

CruiseControl.NET – second impressions …

On our current project we have been running our NAnt build script using a Windows Scheduled Task. While this never seemed particularly sophisticated, it did the job especially given that our build (plus all test suites) takes around 2 hours to run! Today, I installed CruiseControl.NET for a dabble – my last experience was many moons ago – when SourceGear Vault support was still a do-it-yourself affair.

The SourceGear Vault support was flawless – very easy to configure and worked perfectly. Getting the ccnet.config file to work was a little confusing (firstly, realizing that the tag does actually go into ccnet.config not somewhere in ccnet.exe.config as a .NET developer might expect), then the silly hassle with the merge task exception because the docs show the wrong element name (files/file) and that the CruiseControl.NET website with the latest documentation kept going down with proxy errors. (end of rant!) But the persistence was worth it, it monitors the source repository and automatically kicks off builds – then tracking the changes and viewing them in the ASP.NET app that comes bundled.

My initial concerns about CruiseControl.NET waswhat advantage it would give to kick off builds from source file checkins when your build time is 2 hours anyway! It seems that the secret is to limit your essential build tasks to a manageable timely set and then have your longer test suites (typically integration tests) run on a different periodic schedule.

One thing I did notice was that the ASP.NET portion of CruiseControl.NET seems a little slow since it appears to parse the log file on every request to display summary information. This seems inefficient since the log files do not change after the build. Adding a simple OutputCache directive to the Default.aspx page causes the pages to be cached and made the clicking around the UI a much more pleasant experience.

The key benefits that CruiseControl.NETprovides over our scheduled task approach are:

  • Doesn’t wastelessly spin the integration server unless code is being changed
  • Quicker feedback to developers when the build goes wrong (tieing it back to the offending checkin)
  • Easy visibility into the build process which otherwise is a little complicated to debug
  • Summary information on unit test suites
  • Simplified build versioning

If you haven’t tried CruiseControl.NET yet, take it for a whirl!

  1. Aaron Weiker
    November 2, 2004 at 11:22 pm

    I’ve been using cruise control now for about a week and love it. One of the things I ended up doing was running it in a virtual machine to isolate it from everything else and also be able to very easily wipe away the box and start over. The only customization I’ve done so far is to the XSLT pages for displaying the test information. I wanted to see the details of all tests, not just the ones that didn’t fail. It was actually really, really easy to do as long as you are familiar with XSLT.

    Thanks for that info on the page cache, as the page is a little slow when running in a VM.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: