Jenkins New Maven and Gradle Release Management and Why You Should Look Into It?
Jenkins now offers a new robust solution for release staging and promotion in the form of the Jenkins Artifactory Plugin. This solution is fast, lightweight and works for for BOTH Maven and Gradle builds
The Need for a Better Release Alternative
If you are using Jenkins (or Hudson, before) then releasing and promoting build artifacts isn’t necessarily a flawless experience or may not be completely solved. To go over the main reasons of why this is so, I would like to look at Maven and Gradle builds separately.
Maven and the M2 Release Plugin
First, Maven. Jenkins already has a solution for releasing Maven artifacts in the form of the m2 release plugin. The plugin is essentially a wrapper on the client-side Maven release plugin. When it executes it runs an out-of-process Maven build with release tasks. This is natural for a plugin that was designed to run by a user on his machine, but running it server-side has a couple of serious issues:
- The m2 release plugin invokes its own Maven instance that may be of a different version than the one defined for the job. Jenkins, not controlling this build, will not record any information about the release artifacts and will not archive them
- The plugin also uses different SCM settings and credentials than the ones defined inside Jenkins. This double-configuration is error prone, and makes reproducibility difficult
- Rollbacks are hard. With no built-in automatic rollback, when failure happens in the release flow, rollbacks become a manual task. Without a CLI, and given that the run is not interactive, this becomes even harder. Moreover, SCM tags are created with credentials that users may not have access to
- It is unnecessarily SLOW. In fact, a release flow involves 3(!) full clean/compile/test cycles (you can read more about this in this blog post)
Gradle
If you are using Gradle, you are already driving your builds with elegant Groovy model+script. You may want to take advantage of that and enrich your builds with custom release logic via a Gradle plugin, which may be enough for your needs. However, there are some drawbacks to this approach:
- You will need to duplicate the plugin configuration in each new project and introduce release configuration in your build logic. If you run the release from a developer machine, this is fine. However, for the most part this is not the case and releasing from the CI server with greater control and traceability calls for the configuration to be part of the job
- With no strong concept of release “action” that Jenkins can understand, there can be no indicators in Jenkins or in the artifacts repository (Artifactory in this case), that a build was in fact released and that artifacts are part of a release
- As with Maven, rollbacks may require manual intervention and running a release build on the server will not reuse Jenkins job’s setting like SCM details, resulting in dual configuration
Meet the Jenkins Artifactory Plugin
Given all that, we at JFrog, decided to pick up the glove and develop a new release and promotion alternative. The Jenkins Artifactory plugin provides a release management plugin that is:
- Lightweight and fast – only 1 compile/test cycle is required
- Has close integration with your Jenkins exiting configuration, so it reuses the SCM and build settings. The plugin directly integrates with the execution of the Jenkins Maven plugin and the Jenkins Gradle plugin
- Offers very robust and reliable rollback – the plugin is primarily focused on working correctly with GIT and Subversion, respecting the differences between the tools and how tagging and branching is handled in VCS compared to a DVCS, so we don’t have to compromise on a common denominator
- Provides finer control over which properties (in Gradle) or POM versions (for Maven) should change upon release and which ones should also change for the next development cycle
- All commit comments are adjustable and can use Jenkins parameters
When used in conjunction with Artifactory for managing your build artifacts the plugin also –
- Offers advanced control over staging & promotion flow – build artifacts can be staged to a certain repository, and staged artifacts can be either released or rolled-back directly from Jenkins UI with changing of the release status in Artifactory without requiring a rebuild
- Audits all release and promotion actions
- Makes release builds fully traceable by deploying a build-info json object along with the binary artifacts, with information about: environment vars; all artifacts produced; all effective dependencies used; and even all licenses used by those dependencies
- Allows users to attach custom searchable properties to release artifacts upon deployment
Judging by user feedback, the Jenkins Artifactory Plugin really manages to make a difference by providing Maven users with a better alternative and Gradle users with an integrated Jenkins-side solution, for easy staging and promotion experience which is fast and reliable.
Give it a try now and see for yourself 🙂
The Jenkins Artifactory plugin can be found on the Jenkins Plugin Center, with the release management specific page here. All sources are on Github under the Apache 2 license.
Expect similar release management support from JFrog in the next versions of the TeamCity Artifactory plugin and the Bamboo Artifactory plugin
