2011-02-10

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

Update: I updated this article in 2013 as Maven Release Plugin: The Final Nail in the Coffin
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}

Jenkins Config

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.

Nexus Config


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 :-) )

 

Axel

About Axel Fontaine

I'm an entrepreneur, public speaker and software development expert based in Munich.

I'm the creator of Sprinters. Sprinters lets you run your GitHub Actions jobs 10x cheaper on your own AWS account with secure, ephemeral, high-performance, low-cost runners within the privacy of your own VPC.

I also created CloudCaptain, previously known as Boxfuse. CloudCaptain is a cloud deployment platform enabling small and medium size companies to focus on development, while it takes care of infrastructure and operations.

Back in 2010, I bootstrapped Flyway, and grew it into the world's most popular database migration tool. Starting late 2017, I expanded the project beyond its open-source roots into a highly profitable business, acquiring many of the world's largest companies and public institutions as customers. After two years of exponential growth, I sold the company to Redgate in 2019.

In the past I also spoke regularly at many large international conferences including JavaOne, Devoxx, Jfokus, JavaZone, JAX and more about a wide range of topics including modular monoliths, immutable infrastructure and continuous delivery. As part of this I received the JavaOne RockStar speaker award. As a recognition for my contributions to overall Java industry, Oracle awarded me the Java Champion title.

You can find me on 𝕏 as @axelfontaine and email me at axel@axelfontaine.com