2011-02-10

Maven Releases on Steroids (3): Rounding it up with Jenkins

In Part 2, we looked at what changes where necessary to the Maven POMs to make it all work.

In this final part, we'll put the finishing touch by choosing a version number strategy and integrating what we have so far with Jenkins.

Version Number

A good version number has a number of properties:

• Natural order: it should be possible to determine at a glance between two versions which one is newer
• Maven support: Maven should be able to deal with the format of the version number to enfore the natural order
• Machine incrementable: so you don't have to specify it explicitely every time

Typical candidates can be:

• build number
• timestamp (in a suitable format such as yyyy.MM.dd.HH.mm)
• revision number (SVN only)

We must now find one we can use. Luckily for us, it turns out Jenkins has a very useful feature for this. During each build Jenkins exposes a number of environments variables. A few of these are particularly interesting:

Environment Variable	Description
BUILD_NUMBER	The current build number, such as "153"
BUILD_ID	The current build id, such as "2005-08-22_23-59-59" (YYYY-MM-DD_hh-mm-ss)
SVN_REVISION	For Subversion-based projects, this variable contains the revision number of the module. If you have more than one module specified, this won't be set.

In this article, we''ll use the BUILD_NUMBER variable as a version number for our releases. We could have used one of the others as well, but this one fits our need perfectly: a fine machine-incremented number with a natural order supported by Maven.


Jenkins

The first thing to do is to set up a new Maven 2/3 project.

In this project you must

• configure the SCM URL
• set the Maven Goals and options to
  clean deploy scm:tag -DVERSION_NUMBER=${BUILD_NUMBER}

And that's it! Every time this job is run, a new release is produced, the artifacts will be deployed and the source code will be tagged. The version of the release will be the BUILD_NUMBER of the Jenkins project. Nice and simple.


A small note for Nexus users:

In order to allow Maven to upload the corrected POMs from Part 2 of this article, you need to set the Deployment Policy of the Releases repository to Allow Redeploy.



Next step

You're now ready to add a build trigger on SCM changes in Jenkins. Once you have this,every commit causing a green build will produce a new release. It's the next step up.


Download

Last, but not least, here is a sample multi-module Maven Project with all the POMs correctly set up available for download.


Conclusion

Looking back at the workflow of the Release Plugin we discussed in Part 1, we have come a long way!

If you're willing to live with 3 simple things:

• you do NOT depend on SNAPSHOTs, ever.
• the POM does not contain the version number
• you ALWAYS build releases from a CI server, and NEVER locally on a developer's machine

you can now enjoy very fast (3x) and robust releases, without the headaches of the Release Plugin.

For reference:

	Releases on Steroids	Release Plugin
clean/compile/test cycle	1	3
POM transformations	0	2
commits	0	2
SCM revisons	1	3

Enjoy ! (You'll never look back :-) )

 

---

About Axel Fontaine

Axel Fontaine is the founder and CEO of Boxfuse the easiest way to deploy JVM and Node.js applications to AWS.

Axel is also the creator and project lead of Flyway, the open-source tool that makes database migration easy.

He is a Continuous Delivery and Immutable Infrastructure expert, a Java Champion, a JavaOne Rockstar and a regular speaker at many large international conferences including JavaOne, Devoxx, Jfokus, JavaZone, QCon, JAX, ...

You can follow him on Twitter at @axelfontaine