Wednesday, February 25, 2009

Hudson for .NET Projects

I’ve been working on some SharePoint projects recently, and I wanted to implement Continuous Integration(CI).  Unfortunately, I did not find much information when I was researching CI for SharePoint projects.  My company traditionally uses CruiseControl.NET for its standard .NET projects; however, CC.NET seemed to require a good bit of configuration to get started.  I was looking for something I could spin up rather quickly.  I had heard Java folks raving about Hudson's ease of use out of the box, so I wanted to see if the same held true for .NET and SharePoint projects.  I was amazed at how simple it was.

Since I didn’t see many people in the blogosphere talking about Hudson with .NET (and even fewer talking about Hudson with SharePoint).  I thought I would give a very basic tutorial on the .NET set-up for Hudson.  NOTE: Hudson is a Java .war file, so it requires Java 1.5 or later to be on the machine.

Step One – Download Hudson from

Step Two – If Hudson downloaded as a .zip file, rename it to Hudson.war

Step Three – Run Hudson from the command line, by executing the following line:

java –jar hudson.war

Step Four – Now that Hudson is running, pull it up in the browser.  By default, it will be running at http://localhost:8080/

Step Five – Hudson does a lot of things out of the box, mostly centered around Java tools.  So to get .NET projects up and running, we’re going to need to download some plugins.  Hudson makes this incredibly easy.  From the home page, click on the “Manage Hudson” link.  Then, on the manage screen, click on the “Manage Plugins” link.

On the Manage Plugins page, select the "Available" tab and select the tools required for your build.  As you can see in the screenshot below, there are plugins for MSBuild and MSTest, but I have selected NAnt and NUnit as my tools of choice.  There is a TFS plugin, but I haven’t used it yet.  I am currently using Subversion on my projects


Once the plugins have been installed, you’ll need to restart Hudson. 

Step Six – From the home page, click on the “Manage Hudson” link.  Then click on the “Configure System” link.  This screen will allow you to configure the email server and the default Nant installation.  


Now you’re set for adding projects.  And now for the easy part…

Step Seven – Add a new job.  Click on the “New Job” link to start the wizard for adding new jobs.  Enter a name for the job and make sure you have selected “Build a free-style software project”


The next page of the wizard allows you to set up the details of the job (where to pull the code from, how to trigger the build, which build scripts to execute,  how to publish results, and who should receive email notifications).  Note: I did find a limitation when working with NAnt build scripts.  A job will only execute one NAnt script.  This isn’t too bad of a limitation, you will just need to aggregate some targets in a single target of your build file.



Comparing this with other CI tools I’ve used in the past, Hudson is the easiest and has the fewest limitations.  I have used tools that required heavy custom xml configuration, had severe limitations (would not poll source control for changes), or were only built for one platform.  Hudson walks you through all necessary configuration on its UI, without being a hindrance to getting things done.  It is very flexible in what it can do, and has amazing support with a variety of plugins.  Finally, it is not just set up for one platform.  Although it requires Java to execute, there is support for a variety of platforms and languages.

Thursday, February 5, 2009

Continuous Integration: Should we always use it?

I had a conversation with a friend last week that got me thinking a lot about Continuous Integration.  I was explaining, with pride, that I had configured Hudson to build, run unit tests, and deploy SharePoint web parts for my current project.  His response went something like this... "Yeah, Continuous Integration is ok, but it's not really for everything."  His tone showed that he thought its place was in the minority of projects.

That really surprised me.  In 2009, should we be skeptical over the use of Continuous Integration?  Has the case for it not already been made?  This statement was from someone with a similar background to mine, so I was left wondering if I was missing something.

Certainly, there must be a case where we don't need Continuous Integration.  Maybe if you are the only developer on a project and you can build everything yourself.  Wait a minute!  That basically describes my current project!  I am the only person building web parts.  I really value the security of having my code built, tested, and deployed in a an automated fashion on a machine other than my own.  This at least gets me out of the "well, it worked on my machine" excuse.  I also like the fact that Hudson provides a complete history of past builds.

Were there other possible reasons to not use Continuous Integration.  Maybe there is a Return on Investment argument that could be made.  If the amount of effort exceeds the benefits produced, maybe it's not worth the work.  I can immediately see a few holes in this argument.  A tool like Hudson makes the effort invested negligible.  As long as you can script whatever you want to run in CI, Hudson lets you just plug it right in.  If scripting your build and deployment is so expensive that CI isn't worth it, you're probably looking at a symptom of other problems on your project.

In all my reading on Continuous Integration, I don't think I've come across arguments that were just simply against it.  I have seen some arguments that it is part of an evolution, and it does not quite solve all of our problems in its current form.  However, that is more of an argument that we haven't taken it far enough yet.  That's not an argument against using it at all.

So, basically, my conclusion is that Continuous Integration has a place on any professional software development project.  The tools available make the price of entry fairly low.  The benefits by far outweigh the cost of implementing CI.  I didn't really intend for this entry to detail all of the benefits.  This topic has been well articulated in several books, papers, and and many other blog entries.  If you want further reading on the topic, start with Martin Fowler's article.  Books available include Pragmatic Project Automation and Continuous Integration: Improving Software Quality and Reducing Risk.  In the end, I believe its the job of any responsible software developer to ensure their projects take advantage of the benefits of CI.