the life of a particular version of an application or product starts out in development. When it is deemed
ready, it is passed on to a QA team for testing. If they consider the version acceptable, they pass it on to
selected users for more testing in a User Acceptance Testing (UAT) environment. And if the users are
happy, it is shipped out into production. Of course, there are almost as many variations on this as there
are software development teams, but one common principle is that specific versions of your software
are selected, according to certain quality-related criteria, to be “promoted” to the next stage of the life
cycle. This is known as build promotion, and the broader process is known as a build pipeline. In this
section, we will look at how you can implement build pipelines using Jenkins.
10.7.1. Managing Maven Releases with the M2Release Plugin
An important part of any build pipeline is a well-defined release strategy. This involves, among other
things, deciding how and when to cut a new release, and how to identify it with a unique label or version
number. If you are working with Maven projects, using the Maven Release plugin to handle version
numbers comes as a highly recommended practice.
Maven projects use well-defined and well-structured version numbers. A typical version number is made
up of three digits (e.g., “1.0.1”). Developers work on SNAPSHOT versions (e.g.,“1.0.1-SNAPSHOT”),
which, as the name would indicate, are not designed to be definitive. The definitive releases (e.g.,
“1.0.1”) are built once and deployed to the local enterprise repository (or the central Maven repository
for open source libraries), where they can be used in turn by other projects. The version numbers used
in Maven artifacts are a critical part of Maven’s dependency management system, and it is strongly
advised to stick to the Maven conventions.
The Maven Release plugin helps automates the process of updating Maven version numbers in your
projects. In a nutshell, it verifies, builds and tests your application, bumps up the version numbers,
updates your version control system with the appropriate tags, and deploys the released versions of your
artifacts to your Maven repository. This is a tedious task to do by hand, so the Maven Release plugin
is an excellent way to automate things.
However the Maven Release plugin can be fickle, too. Uncommitted or modified local files can cause the
process to fail, for example. The process is also time-consuming and CPU intensive, especially for large
projects: it builds the application and runs the entire set of unit and integration tests several times, checks
out a fresh copy of the source code from the repository, and uploads many artifacts to the Enterprise
repository. Indeed, this is not the sort of thing you want running on a developer machine.
So it makes good sense to run this process on your build server.
One way to do this is to set up a special manual build job to invoke the Maven Release plugin. However,
the M2Release plugin proposes a simpler approach. Using this plugin, you can add the ability to
build a Maven release version in an existing build job. This way you can avoid duplicating build jobs
unnecessarily, making build job maintenance easier.
Once you have installed this plugin, you can define any build job to also propose a manual Maven
Release step. You do this by ticking the “Maven release build” checkbox in the Build Environment