Maven Release Plugin in the Enterprise

Background

Enterprise Customers often ask for measurable ways to show benefits by adopting Application DevOps (App DevOps), also known as Continuous Integration and Continuous Delivery (CI/CD). Many of the benefits of App DevOps (or CI/CD) are hard to quantify. Most organizations don't have a line item in their time-tracking system for activities such as “fixing cowboy coder mistakes” or “up all night finding the correct source code revision to start writing the one-line fix in order to get orders flowing again without unintentionally merging in a bunch of new code that has not been tested.” Tracking total hours spent performing those activities over the course of a year across all development teams can be very difficult. Additionally, with a flood of Enterprise DevOps tools promising to deliver massive ROI, it is challenging for organizations to prioritize financial resources to solve problems that have nebulous value.

My recommendation in these cases is always the same; the biggest bang for your DevOps buck doesn’t cost a dollar. Enterprises can realize immediate time savings by having an automated code artifact release process using the Maven Release Plugin. The benefit of adoption is that the Maven Release Plugin provides a straightforward way to measure the amount of time that is spent performing release tasks, while also eliminating the opportunity for human error during manual processes. Many enterprises dedicate a significant portion of their development time and resources to tasks related to code artifact release.

Automating these steps provides measurable value and increases quality by having a consistent and reliable release process. Additionally, having an automated code artifact release process is critical for organizations looking to adopt Microservice Architecture or use Linux Containers (such as Docker or OpenShift), where the number of released code artifacts and release frequency will be greatly increased.

What is the 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.

What’s the Best Practice for Versioning When Using the Maven Release Plugin?

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

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.    

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.

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.

Recommended build jobs for a code project called widget.service:

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 the 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.

Summary

Enterprises need to transform and modernize their IT applications in order to keep pace with competition and provide better value to customers. DevOps practices help enterprises stay competitive by providing measurable ways for organizations to scale their application development efforts through automation. The most impactful automation to implement with the least time commitment is an automated artifact release process. The Maven Release Plugin provides this automation with no upfront software costs.

References

Apache Maven Release Plugin website

Note: Apache and Maven are a registered trademark of the Apache Software Foundation.