Saturday, 14 January 2012

Why use the Hudson jobcreator tool?

It might seem very counter intuitive to start using Hudson's XML format to manage Hudson  jobs when it has such a great web interface, especially since it is the web interface which has made Hudson so approachable and easy to use.

Don't get me wrong. I still love the web interface and think it is the right way to get people to use the tool, however I also think there comes a time when you outgrow the web interface and this is why I built the jobcreator tool.

These are the requirements and issues that caused me to outgrow the web interface:

Manual changes doesn't scale
Using the web interface to make changes to individual jobs is very easy, but it doesn't really scale if you need to change a lot of jobs on the same time. One example could be changing the git branch from "master" to a release branch for all the jobs related to a environment, Such a change could involve upwards of 30 jobs.

Another example could be that there are changes to the content and/or structure of the jobs and those must be propagated up through the environments in sync with project code.This would be even more manual changes.

Managing this with manual changes in the web interfaces introduces a big risk for human error and inconsistencies.

Hudson jobs are code
If you want to be able to reproduce a build or deployment at a later time it is important that you can also reproduce the Hudson jobs. In order to do this you need to store and version your Hudson job configurations.

This is naturally best done in a SCM like Git or Subversion. Doing so also gives you the option to do branched development of your jobs.

Testing and more than one Hudson instance.
Before making changes to the jobs being actively used the changes should naturally be tested somewhere. This normally means creating the same set of jobs somewhere else or targeted towards a different environment.

Having the jobs defined as templates makes it easy for a developer to load the jobs into a private Hudson instance to experiment or share it on the testing instance.

Of course Hudson can be managed via the web interface, but for me it is just another step in the automation.

No comments:

Post a Comment