Tuesday, August 12, 2008

Build Promotion with Hudson

I can't say enough good things about hudson. It's become a crucial part of our development platform. For those not familiar, Hudson is a continuous build server, much like cruisecontrol, but on steroids.

Our build process looked a little like this.

  1. Developer makes changes locally, commits to subversion
  2. Hudson detects changes, kicks off the compilation
  3. 3 Times a day, hudson would run the junit tests (about 25 minutes)
  4. 3 Times a day, hudson would run our xml api tests (about 10 minutes)
  5. 3 Times a day, hudson would run our Webtest tests
  6. Every two weeks or so, development would ask me to make a release build which would be published to our QA department.
This process was ok, but it is pretty inefficient. Each testsuite run could be executed on a different svn revision. If QA received a build with a serious problem, it became a big hassle to get them a new one.

My goal is to be able to turn around development changes in a much quicker fashion and get them into the hands of the qa group.

Enter hudson and build promotion. The idea here would be that for each checkin made by development, that subversion revision will go through a promotion process. Here is the process:

  1. Developer checks in code ->
  2. Hudson compiles code and builds our the ear ->
  3. Hudson zips up that project workspace and publishes it as an artifact for other jobs to consume
  4. The junit job is kicked off against the zipped workspace ->
  5. The api tests are kicked off against the zipped workspace ->
  6. The webtests are kicked off against the zipped workspace
  7. If all testsuites pass with zero errors, the build is "promoted" and is available for qa to test
  8. There may be several promoted builds per day/there may be 0.
How do I accomplish this in hudson?

  1. Install the build promotion plugin
  2. Configure your main compilation job use the build promotion plugin. You'll also need to add an ant target to zip the workspace and publish it as an artifact.
  3. In your child jobs, add a bootstrap target which downloads and explodes the zipped workspace. Remove any scm configurations from them.
  4. Finally, link your child jobs to the parent jobs via the promotion plugin configuration.


  1. After things are promoted, they simply get a start next to them. I'm looking into the modifiying the promotion plugin so that it can perform more actions such as scping the artifacts to a webserver after they are promoted.
  2. I need to figure out a way to associate the sum of defects changed from 1 build to another and report them.

1 comment:

Frank GE said...

This article describes 'automated triggering'. This is not the same as promotion. Promotion occurs when a person decides that a specific build should be 'promoted' to a further process. Until we have tools that can determine when 'all changes are complete', 'the customer needs a new build' and/or any other person based decision, we need both automated triggering and promotion.