What is Maven Release Plugin?

The Maven Release Plugin automates common steps taken when releasing a version of a code artifact:

1. Update the version number to a stable release number
2. Create a “tag” in the source control management system (such as SVN or Git) to identify the point in time when the release occurred
3. Deploy released artifacts into a Maven Repository (such as Nexus or Artifactory) to make the code artifacts available for deployment to servers or to be used by other developers
4. Update the source code to the new version number for use in development

What’s with the blog posts complaining about the Maven Release Plugin?

The complaints I’ve seen about the Maven Release Plugin can be grouped into two core issues:

1. Version Numbering (attempting to use a non-Maven version numbering scheme)
2. Complexity in rolling back or “undoing” a release if there is an issue

Both of these issues can be traced back to same issue: the desire to have a specific version number at a given time. Adopting an organizational approach to match the behavior of the tool eliminates both of these issues and allows organizations to move forward very efficiently.

Many organizations have used a version numbering scheme for years. The most common process is to determine a target version number ahead of time and scheduling a specific version to release with specific Sprint activity or Project intervals. While there is nothing inherently wrong with this practice, it complicates the process and does not work well with the version numbering inherent with the Maven Release Plugin.

The Maven Release Plug defines version numbers as:

[major].[minor].[incremental]-[qualifier]

For example: The version number “3.0.1-SNAPSHOT” is used for all development build created ahead of a “3.0.1” release.

Understanding how Maven versioning works and how to best utilize it will eliminate a lot of common issues.

"A stated goal should be that code artifacts move unchanged from QA to Production, limiting the risk of an error creeping into Production during the release cycle"

What’s the Best Practice for versioning when using the Maven Release Plugin?

1. Enterprise IT Projects should identify milestones as releases containing features or bug fixes, and not focus on a specific version number.

   Recommended Best Practice:
   Sprint 12 Release: Updates to include support for widget Y and bug fixes for widget X

   Not Recommended:
   Sprint 12 Release: v3.0.1 updates

   Note: The version number should be an output of the Sprint activity or Project interval, not decided ahead of time.

2. Each release of a code artifact does not necessarily get deployed to production.

   In the examples below, when QA finds a bug in v3.0.1, development needs to provide a v3.0.2 release for certification testing. Once v3.0.2 passes QA, it would be suitable to release to Production, bypassing any production release of v3.0.1.
   

   

   A stated goal should be that code artifacts move unchanged from QA to Production, limiting the risk of an error creeping into Production during the release cycle.

   
   
3. DevOps teams should create automated code artifact build jobs in order to standardize the process and not burden developers with having to become experts in the Maven Release Plugin.

   Below is a sample of standard build jobs that should be created:

   Recommended Build Jobs for a code project called “widget.service”:

   widget.service-SNAPSHOT	This is the standard build for development tasks
   widget.service-SNAPSHOT-no-tests	A fast build that by-passes unit testing
   widget.service-RELEASE-dry-run	A build that simulates a release, but does not perform the steps. Should be run before the RELEASE builds in order to identify problems ahead of time.
   widget.service-RELEASE	The release build
   widget.service-SNAPSHOT-update-version	A build that allows the user to enter the new version number for development. This is needed when updating major or minor version numbers. For example moving from “3.0.4-SNAPSHOT” to “4.0.0-SNAPSHOT”

What are the gotchas?

Choosing not to utilize the Maven version numbering scheme will backfire, and not produce the benefits that could be attained. The Maven Release Plugin is best utilized with a standard Maven versioning scheme.

1. Development tasks occur with qualifier “–SNAPSHOT for example, 3.0.1-SNAPSHOT
2. Release tasks have clean version numbers: 3.0.1
3. Attempts at using non-Maven versioning schemes create more work and generally provide negative business value

What is hype?

For automated code release processes, the hype factor is zero. The benefits are very real when adopting an automated code artifact process. An automated release process is practically a requirement for organizations looking to adopt Micro Service Architecture and Containers. The Maven Release Plugin provides this with no upfront cost.

How do I ensure success?

1. Learn and adopt the Maven version numbering scheme.
2. Adopt a project plan or Sprint planning process that does not target a specific release version number, but rather a set of features or bug fixes.
3. Perform QA testing against released versions of artifacts, not “SNAPSHOT” development builds.