DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • How to Publish Artifacts to Maven Central
  • Release Pipeline Using Azure DevOps
  • Mulesoft 4: Continuous Delivery/Deployment With Maven
  • Fast Deployments of Microservices Using Ansible and Kubernetes

Trending

  • A Complete Guide to Modern AI Developer Tools
  • Hybrid Cloud vs Multi-Cloud: Choosing the Right Strategy for AI Scalability and Security
  • Solid Testing Strategies for Salesforce Releases
  • Beyond Linguistics: Real-Time Domain Event Mapping with WebSocket and Spring Boot
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Maven Release Plugin in the Enterprise

Maven Release Plugin in the Enterprise

Matt Pavlovich explains what the Maven Release Plugin is, why some people have been complaining about it, how to ensure success when using it, and more.

By 
Matt Pavlovich user avatar
Matt Pavlovich
·
Oct. 18, 16 · Opinion
Likes (4)
Comment
Save
Tweet
Share
6.0K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Image title

Image titleRecommended build jobs for a code project called widget.service:

widget.service-SNAPSHOT

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

Apache Maven Release (computing) Continuous Integration/Deployment Artifact (UML)

Opinions expressed by DZone contributors are their own.

Related

  • How to Publish Artifacts to Maven Central
  • Release Pipeline Using Azure DevOps
  • Mulesoft 4: Continuous Delivery/Deployment With Maven
  • Fast Deployments of Microservices Using Ansible and Kubernetes

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!