Java professional, Cofounder and CTO of JFrog, and creator of the Artifactory OSS project. JavaOne, QCon, TSS, Devoxx and JavaEdge speaker. Holds a CS Masters from the Royal Melbourne Institute of Technology in Australia. Yoav is a DZone MVB and is not an employee of DZone and has posted 7 posts at DZone. View Full User Profile

Jenkins New Maven and Gradle Release Management and Why You Should Look Into It?

06.02.2011
| 9984 views |
  • submit to reddit

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, rollback becomes 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 with 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 builds was in fact release and that artifacts are part of a release.
  • As with Maven, rollback 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 Jenkins Maven Plugin and Jenkinn 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 change 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 released artifacts

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

 

From http://blogs.jfrog.org/2011/06/jenkins-new-maven-and-gradle-release.html

Published at DZone with permission of Yoav Landman, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)