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