Setting the Hudson/Jenkins next build number programatically

Programatically setting the next build number in Hudson/Jenkins is a useful thing to do if you have a build pipeline. After a bit of research it seems there are 3 main approaches that could be useful in different situations:

1. Set the nextBuildNumber.txt in your Hudson job's directory
2. Use environment variables for build number passthrough (see @ruby_gem's post here)
3. Use the nextBuildNumber Hudson plugin and HTTP POST the build number to it

In this post I'll be looking at option 3 - using the nextBuildNumber Hudson plugin.

Using the nextBuildNumber Hudson plugin

Firstly install the nextBuildNumber plugin. You can now set the next build number for a job manually from the plugin link that appear on the left.
To use this programatically you simulate the manual for submission with a web client. I tested it with FireFox ReST client.
To set the next build number to 999 simply formulate an HTTP POST to your Hudson URL:

e.g. http://myhudsonserver:8080/job/myhudsonjobname/nextbuildnumber/submit

With the form data

nextBuildNumber=999

And the HTTP Content-Type request header

Content-Type: application/x-www-form-urlencoded

If your Hudson is secured you'll need to authenticate your web client too.

That's it! Finally it's worth noting that build numbers in Hudson can only go up!

Error Handling CI Deployments Using Powershell

PowerShell's a great tool for use in remote deployments from a CI server. However, it's default error handling does not cause a failure on error which can leave failed deployments reporting success!

To make PowerShell scripts fail on non-terminating errors add the following line to the top of the script after any params:

$ErrorActionPreference = "Stop"

This will cause the script to fail on terminating and non-terminating errors hence preventing the Powershell script succeeding when elements of it have failed.

Breaking The Legacy Bind : A Tale Of Build Automation

I've recently moved teams and following a brief honeymoon on a greenfield web app we're now swimming in the murky waters of the "Legacy Codebase". Imagine a world with no continuous integration, patchy test coverage, untamed dependencies, COM+, a long manual build and deployment process and to top it all off, Visual Source Safe.
If this doesn't make you shudder then best stop reading now :)

Granted, there are probably many worse legacies out there and much of our underlying code is good but it's still a significant departure from the instant builds and frequent releases we had been making.

Science Friction

The initial obstacle faced here is friction in the development process. Friction resulting mainly from the repetitive manual build process. The manual build takes time; lengthening the feedback cycle. It's also tedious and error prone. These two facts alone can prevent even the most diligent of developers from making the refactorings necessary to keep the codebase in good health. Our first job - automate.

Automation, Automation, Automation

Automating the build process to run on check-in removes the tedium of doing it manually and is relatively easy to do with any CI server. Fortunately our code already has a well organised suite of NAnt scripts so we simply configured Hudson, our CI server, to run them and display the test output. A relatively quick win.

If you're not so lucky you could start with automating one part at a time. Just note down your manual process and automate each step in turn.

Migration From VSS To TFS

Using Hudson mandated the source code be migrated from Visual Source Safe to a system more suitable for use with a CI server - in our case Team Foundation Server. The migration itself is fairly straightforward with the Microsoft migration tool and instructions but can be time consuming so plan carefully, especially if your VSS repository is in constant use.

I've previously done this from VSS to SVN and there are probably tools out there to move between most source control systems, but beware, not all features are supported by all systems e.g. VSS pinning, SVN externals. Of course, if you're not concerned about the history, tags etc. you can always just check-in a fresh copy from your old source control to the new one and get going straight away.

Verify The Build

The first build is by far the biggest risk and taking the time to verify it is very worthwhile if you care about the quality of your software. This cost us a couple of days due to build/env issues but it's either that or the entire thing is a no-go so don't be tempted to scrimp here!

Comparison tools such as WinMerge and BeyondCompare can help here to compare the checkouts from each source tree or even build artefacts.

Building For The Future

We're not done here! An automated build is a huge leap forward and allows you to concentrate on skilled activities that deliver more value but it's by no means the end.

Build time is important and reducing it is next on our hitlist. Time spent waiting for a build is often time wasted or forces you into the undesirable world of multitasking. If your build takes longer than it does for you to make a cup of tea then there may well be room for improvement.

Final Thoughts

Dealing with unfamiliar or hard to work with code can be daunting. In my (limited) experience it's all about confidence - get stuck in, and little by little you'll find a path forwards. If you're struggling then I'd highly recommend Michael Feathers' Working Effectively With Legacy Code (ISBN 0131177052) for some inspiration.