2011-01-23

Maven Releases on Steroids: Adios Release Plugin!

One of the central themes of my current series of talks about Continuous Delivery is releasing software.

Releasing software encompasses a number of activities such as

• Picking a version number
• Checking out the latest revision from SCM
• Building and Testing binaries
• Tagging the SCM revison with the version number
• Publishing the binary artifacts in an Artifact Repository
• Writing release notes, announcement e-mails, etc...

In order to avoid the Works On My Machine syndrome, releases are typically built centrally on a continuous integration server such as Hudson Jenkins.

The Continuous Integration server serves as a choreographer between the following components:

• SCM (Subversion, Mercurial, Git, ...)
• Build Tool (Maven, Ant, Gradle, ...)
• Artifact Repository (Nexus, Artifactory, ...)

On Maven projects, the Building, Testing, Tagging and Publishing steps have traditionally been handled by the Maven Release Plugin. It works, to a reasonable degree, and it has a decent Jenkins plugin.

Using Jenkins and the Release Plugin, here are the typical steps performed by the various components:

(Safety Notice: buckle up, it's going to be a wild ride!)

• Jenkins checks out the latest revision from SCM
• Maven compiles the sources and runs the tests
• Release Plugin transforms the POMs with the new version number
• Maven compiles the sources and runs the tests
• Release Plugin commits the new POMs into SCM
• Release Plugin tags the new SCM revision with the version number
• Release Plugin transforms the POMs to version n+1 -SNAPSHOT
• Release Plugin commits the new new POMs into SCM
• Release Plugin checks out the new tag from SCM
• Maven compiles the sources and runs the tests
• Maven publishes the binaries into the Artifact Repository

Phew! Did you count it?

That's 3 full clean/compile/test cycles, 2 POM transformation rounds and 3 different SCM revisions!

No wonder this thing has proved to be error prone and frustrating to many developers for years now. And let's not even get me started on how well this thing blows up when another team member unsuspectingly checks in a change to the POM in the middle of this multiple transform and commit carousel...

So is there another way?

What if we could deal with only a single SCM revision (the one we want to release) going through a single clean/compile/test run before tagging the source and publishing the binaries?

Let me say this loud and clear: yes, we can!

The solution I present in part 2 does just that. This is what it looks like:

• Jenkins checks out the latest revision from SCM
• Maven compiles the sources and runs the tests
• Maven tags the SCM revision with the version number
• Maven publishes the binaries into the Artifact Repository

Simple and to the point.

Continue to Part 2 where we go into the adjustments to make to the POMs.

 

---

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