Subscribe to the MPC blog rss feed feed-icon-14x14
 

Using CruiseControl.Net To Automate Project Builds, Testing and Deployment

Posted on 01:32AM on 02/14/2009
Tags: dotNet, CruiseControl

It's been a while since I've posted. Things have been busy, but that's no excuse.

Today I wanted to discuss CruiseControl.Net and how useful it can be. What is CruiseControl.Net? It's a port of the Java based Continuous Integration framework CruiseControl. From now on, I'll refer to CruiseControl and leave it at that, since most of my points can be taken in the context of either. Lots of people use and have written about CruiseControl. This is just an account of my experiences. If you are looking for a technical article with lots of instructions, you should look elsewhere as I don't want to rehash what's already been extensively covered.

My scenario:

Recently I was working on a large, pre-existing .NET web application. It was reasonably well written, but was severely lacking in both unit and functional tests. Determining whether it would build properly or not was a manual exercise. 

There were a couple of issues we wanted to solve:

  1. Running unit tests
  2. Running functional tests
  3. Building and deploying of the application
  4. Notification when things

 

We decided that unit tests and functional tests (using WatiN) were necessary. It would be foolish to try to write tests to cover the existing codebase, but going forward, we would write unit tests for new code. Additionally, we would write tests whenever we refactored the existing codebase. Functional testing would be handled slightly differently since we had a person who would be soley responsible for UI and functional testing. We knew that we wanted unit tests run whenever code was commited to source control. The functional tests would run nightly.

Another problem was that of build and deployment verification. Did the codebase build? Could you build and run the installer project?

Finally we wanted to be notified when there were problems.

CruiseControl helped us deal with these things and so far has been running very smoothly.

Setting up CruiseControl was fairly straightforward. After downloading and running the installer, I configured the Dasboard website that CruiseControl installs to allow developers easy remote access to the status of the build. There was one minor glitch in that the web.config file needed to be modified to run on Windows Server 2008 and IIS7. The details can be found here.

Next, I configured the CruiseControl server using the ccnet.config file. This consisted of defining the projects that CruiseControl would manage. Within each project you define:

  1. The project's source control repository 
  2. A trigger (which tells CruiseControl when to rebuild the project)
  3. Any number of tasks
    1. Build the project
    2. Run unit tests
    3. Build the installer
    4. Uninstall the previous version
    5. Install the new version
    6. Run WatiN tests against the newly installed application
  4. Publishers - Email failure results, merge build and test files, etc.
  5. There are other things as well. See here.

 

The last thing to do was to install the CCNet client, a desktop application that sits in the system tray and monitors the server for changes. It notifies you when a build fails, suceeds, etc. You can also use it to force a build or to navigate the the web dashboard.

On the whole, CruiseControl seems to really have helped the development process for that project. The development team has much more confidence in their product. They know that they are beginning to get a good amount of code coverage. They know that their product builds and installs correctly. When any of these are not true, the developers are quickly made aware and can fix the problem.

0 Comments (Show) (Comments are closed for this post)

Please note that I am currently unavailable for any large, long term work.