Archive for the 'Hudson' Category

Hudson – Continuous Integration Testing

For a while now we’ve been planning on making use of Hudson to help us maintain working builds in our source code configuration system.

What Hudson does, is build your software at a predefined schedule (like a SQL Server agent job, or Windows Scheduled task) or when requested by a user, and produces a dashboard showing the status of your software builds. It is highly configurable, and can link to many source code control systems to get the latest version of your latest code.

Even though this product was/is/seems to be (I’m not sure on this) aimed at the Java developers of this world, it can build pretty much any software package.

We intend to make use of it for the building of .NET applications by getting it to call MSBUILD via DOS Batch files (in my example), however I will point out that you can get Hudson to call MSBUILD through an MSBUILD plug-in not covered in this post.

I want to use another plug-in, the ‘Text Finder’ plug in to parse the output of the batch file for StyleCop errors and system build failures.

Please have a read of this: Meet Hudson, so you can get a proper introduction to it.

To be perfectly honest, I’m not a Java fan (as my colleagues will tell you ;-))… and I thought it was a little overkill to have to install a Java Runtime and Apache, and Hudson to perform automatic builds… however, it has been relatively painless… and as my organisation is not exactly liking to splash to cash at the moment, the fact that everything is free helps…

Those risk adverse, like myself, have to put aside the fact that it’s all open source… and the only support out there is through volunteers :-)… there’s no metaphorical stick to hit someone with if the product doesn’t ‘just work’ out of the open source box.

What I downloaded

  1. Java Runtime Environment (jre-6u14-windows-i586)
  2. Tomcat 5.5 (apache-tomcat-5.5.27)
  3. Hudson (hudson.war v1.314)
  4. Text Finder plug in (text-finder.hpi v1.7)

NB: If you are using IE8/7 to download hudson.war and text-finder.hpi you may find that the extension is changed to .zip. You will need to rename the files back to their original extension to get the installation to work correctly.

Setting up Hudson on Windows 2003/2008 Server alongside IIS

Obviously, since apache tomcat and Hudson are Java based applications, if you don’t have a Java Runtime environment (JRE), you’ll need to install that first. It is relatively painless, simply double click on the EXE installer and bob’s your uncle.

I had my doubts about getting Tomcat 5.5 working alongside IIS, but to my surprise (I haven’t touched Tomcat since my University days back in 2001) the installer worked well, and defaulted to using port 8080, which is nice, since I don’t want to be getting in the way of IIS on port 80. The installer *should* also detect if you’ve got a JRE installed and set the link to it up automatically. If it doesn’t, simply point the installer at the folder that you installed the JRE. You need to set an administrator account up to access the Tomcat manager.

The Tomcat application server should be alive (possibly following a reboot in certain circumstances) after the install and you should be able to navigate to it’s front page.

tomcat_001 
Figure 1: The tomcat front page

imageFigure 2: Entering tomcat manager

Open the Tomcat manager to instigate the Hudson installation. It will prompt you for the username and password you set up during the Tomcat installation before you can access the page.

Scroll down to the Deploy section, in the ‘WAR file to deploy’ section click browse, and select the hudson.war file we downloaded earlier.

tomcat_002
Figure 3: Deploying the Web Archive (WAR) for Hudson

Click the deploy button and the application should be deployed. If you put the WAR file in a part of the file system that gives a long file path, e.g. ‘C:\longfilepath\longfilepath\longfilepath\longfilepath\longfile\hudson.war’ you may have issues with the deployment. I certainly encountered this issue last week. The error message you will get isn’t the most useful, so it’s worth moving it to the root of a drive to see if that solves it.

To confirm successful deployment, look at the application list

tomcat_003
Figure 4: the application list, showing Hudson

If you click on the hyperlink ‘/hudson’ it should take you to the front page of the Hudson application.

tomcat_004 
Figure 5: The Hudson ‘dashboard’

You are now ready to go… as you might have noticed I’ve already created a Job - ‘Test 001’. This is the build that I’ve set up to hopefully explain to you as part of this post.

As I’m using the ‘Text Finder’ plug-in, you’ll now need to install that if you want to follow my example.

tomcat_005 
Figure 6: Managing Hudson, and adding a plug-in

Click ‘Manage Hudson’ and then on ‘Manage Plugins’, Click the ‘Advanced’ tab and scroll to the bottom of that page so you see the following:

tomcat_006
Figure 7: Uploading a plug-in

If now click the upload button, when it has finished, restart the Tomcat service. If you don’t perform a restart the plug-in wont be shown as installed.

image
Figure 8: list of installed plug-ins

Once installed, you should see it in the list of installed plug-ins.

We can now go about creating the job that will build the .NET application.

I’ve got a really simple .NET 3.5 website application (it does nothing other than to display default.aspx) that I’m using for this post.

tomcat_007
Figure 9: Visual Studio 2008 Web Application, the working folder on E: drive and the batch file in the root of the web application folder.

The batch file that Hudson will call is very simple, and I suspect it could be done better, however, here it is if you want to make use of it:

echo change directory to visual studio 2008 common tools folder
cd /d %VS90COMNTOOLS%
cd ../..
cd VC
echo set environment variables
call vcvarsall.bat;

echo call Test001.csproj (looks in the directory of this batch file for it)
call msbuild %~dp0Test001.csproj

Navigate to the Hudson ‘dashboard’/front page. And click ‘New Job’.

Provide Hudson with a name for your job, and select ‘Build a free-style software project’.

image
Figure 10: Free style software project selection

tomcat_008
Figure 11: Adding build steps

Leave everything else as standard for now, and click ‘Add build step’ and select the ‘Execute windows batch command’ option.

Enter the path to the batch file (as shown in Figure 12)

tomcat_009
Figure 12: entering the batch file details into build step

The next step is to configure the ‘text finder’ plug-in to look for the token ‘FAIL’, since MSBUILD produces messages with the word ‘FAIL’ in them.

tomcat_010
Figure 13: configuring Hudson to look for the token ‘FAIL’ in the console output.

Click the Save button, and your job has been created!

Navigate back to the Hudson dashboard, and click the ‘build’ icon next to Job ‘Test 001’ (as shown in Figure 14)

tomcat_011
Figure 14: Instigate a build

If the build was successful, when you refresh the page, you should see this:

image
Figure 15: The sunny picture indicates a very stable build

To demonstrate how Hudson picks up on failed builds, I’m now going to rename the code behind page for default.aspx from ‘default.aspx.cs’ to  ‘breakbuild.aspx.cs’.

image
Figure 16: Deliberately breaking the build

Using Hudson, run the job again.

image
Figure 16: The cloudy picture indicates a failure has occurred

The job has failed, the more the job fails, the worse the weather gets :-)

Run it a few more times to get more bleak weather (unless you like thunderstorms).

image
Figure 17: thunderstorms indicate that most recent builds have all failed

You can review the console output of all the builds that have taken place to help you diagnose failed builds.

tomcat_012
Figure 18: review console of failed builds

As you can imagine, with the text finder plug-in and the numerous others available for Hudson, it makes it a very powerful tool.

I intend to set ours up so it will notify the development team when the latest version of a system checked into our source control system will not build, or contains StyleCop warnings.

SpittingCAML




You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.