Maven Renewed: An Old Friend Reworked for a New Release World
Semantic Versioning is a critical-path component for robust release processes, but in a world of rapid release and deployment cycles it alone is not enough. Developers, QA testers, SREs and Devops engineers benefit from more precise coordinates that link software releases to constantly evolving codebases. As one of the most established, highly used and stable build systems, Maven implements a mature Semantic Versioning process through its Maven Release Plugin. The process involves a series of serial steps that change configurations, perform compiles and unit tests, push SCM commits and lock-down SCM revisions. Revisions are 'x.y.z-<qualifier>' where the qualifier may include a descriptor, such as 'SNAPSHOT' to denote a development build or 'yyyyddmm-hh:mm:ss' to denote the moment of build completion.
How can version numbers provide better information? This isn't a question as to the utility of Semantic Versioning but how to enhance it. Simple answer: Versioning can tie back to exact SCM commits and continuous integration build identifiers by including that precise information in the version numbering scheme itself. OSS projects show that precise versioning is often better, but also that excessive detail in a large development environment can amount to useless information overload. (Is there really a need for time-stamping every single snapshot in an environment of numerous commits?)
The Maven Release Plugin performs software releases in a series of preparation and execution steps ('mvn --batch-mode release:prepare' and 'mvn --batch-mode release:perform'). These steps are executed synchronously and include 10 incantations of operations described previously, defaulting to three clean/compile/test cycles. Thus, for a 10-minute-long clean/compile/test cycle, a release will take over 30 minutes. In this traditional implementation, devops staff and developers may be starved of build status until near the end of a given release cycle, eating precious moments in a fail-fast obsessed culture. Worse, with multiple moving pieces in motion all the time, it becomes difficult to tie back a time-based release object.
In this presentation, Maven is reinvigorated, reworking the release process to a minimum number of cycles and limiting the noise in an ever-changing development environment. Simultaneously, versioning is improved in ways that yield quickly tying versions to exact commits and to build testing on CI platforms. The build above that required a 30-minute release window is reduced to a simple 10-minute cycle that provides better coordinates to its originating code and CI test builds.
With its 3.5.x release, Maven supports dynamically injecting specific values into POM version elements with submodule inheritance. The new approach completely removes the Maven Release Plugin from the process. In its stead, software coordinates are described with POM properties that allow injection of unique external identifiers commonly available in complementary tooling, like Git, Jenkins or a number of other platforms. Then, a reworked SCM-plugin approach allows tags to be deployed without the Release Plugin process thereby reducing overhead from 10 to two total operations.
Because Maven is a modular, plug-in-based build system, it offers the flexibility to be reworked, essentially making it a renewed product. The new approach makes releases fast enough to generally outweigh benefits gleaned from other, potentially more complex products with a higher learning curve. The ability to tie release versioning back to both integration builds and specific code commits makes it a more powerful tool for the CI/CD pipeline and brings it up-to-speed to meet the demands of modern release pipelines.