Tuesday 7 February 2012

Ivy based subproject as maven module

I have previously written about the challenges of integrating an Ivy based subproject (like the play framework) into a build that is otherwise Maven based. After some work it is now working although the support feels a bit rudimentary.Here are the highlights on how to make it work

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.

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

Friday 13 January 2012

Announcing the Hudson job creator tool.

I have finally had the chance to pull together the last changes before announcing the first version of the Hudson Job Creator tool.

The idea behind the tool is that you can write FreeMarker based templates and combine those with properties defined in a "pipeline" specification in order to generate Hudson's job config.xml files.
This is mainly useful if you maintain a number of similar jobs, or have a series of jobs that you need to specify for multiple environments.

I know working with Hudson's xml files directly can seem counter intuitive since one of Hudson's main strengths is its approachability and easy to use web interface, so later this week I will post a more in depth blog post
explaining why I chose to go this route.

All the information about the tool including download is available on github, https://github.com/hudson-plugins/jobcreator-tool .

Sunday 8 January 2012

Maven bug fixed making Hudson's Maven3 integration much more useful

Back in July when I reviewed the Maven3 integration in Hudson 2.1, I made a point regarding it not working when doing a maven release. As written back then the cause is a Maven bug (release:prepare does not pass argument "--settings" with current settings.xml to inner maven).

This bug has now been fixed and a new version of the release plugin has been released. So if you update the release plugin to version 2.2.2, Hudson's maven3 integration will now work for releases also.