General

The Artifactory plugin includes release management capabilities for Maven and Gradle runners that use Subversion or Git for VCS.

The plugin lets you manually stage a release build, allowing you to:

• Change values for the release and next development version
• Choose a target staging repository for deployment of the release, and
• Create a VCS tag for the release.

Staged release builds can later on be promoted or rolled-back, changing their release status in Artifactory and, optionally, moving the build artifacts to a different target repository.
Inside Artifactory the history of all build status change activities (staged, promoted, rolled-back, etc.) is recorded and displayed for full traceability.

Maven Release Management

Release management with Maven is done entirely by the plugin and executes the Maven build only once.
These are the basic steps that the plugin performs:

1. Change the POM versions to the release version (before the build starts)
2. Trigger the Maven build (with optionally different goals)
3. Commit/push changes to the tag (Subversion) or the release branch (Git)
4. Change the POM versions to the next development version
5. Commit/push changes to the trunk

In case of a failure, the plugin will do its best to rollback the changes (local and committed).

Configuring Maven Runners

To enable release management in Maven runners, edit the runner's step configuration and check the "Enable Artifactory release management" checkbox.

Staging a Maven Release Build

Once the release management is enabled, the Artifactory Release Management tab will appear on the top end of the build page.

Clicking on the tab reveals configuration options for the release build:

The release staging page displays the last built version (the version is of the root pom and it is taken from the last non-release build).
Most of the fields in the form are filled with the default values.
Version configuration controls how the plugin changes the version in the pom files (global version for all modules, version per module or no version changes).
If create VCS tag is checked (default), the plugin will commit/push the poms with the release version to the VCS system with the commit comment. When using Git, there's also an option to create a release branch.
If the target Artifactory server is the Pro edition, the last section lets you change the target repository (the default is the release repository configured in Artifactory publisher) and to add a staging comment which will be included in the build info deployed to Artifactory.
Click on the "Build and Release to Artifactory" button to trigger the release build.

Promoting a Release Build

After a release build finished successfully it is possible to promote the build. This is not a required step, but very useful if you want to mark the build as released in Artifactory and to move/copy the built artifacts to another repository so the artifacts will be available for the consumers.
To activate the action browse to the build's result page and click the Artifactory Release Promotion link.
Note that Artifactory Pro is required for promotion.

Clicking on the link will open the promotion dialog:

Select the target status (Released or Rolled-Back) of the build and optional comment to display in the build in Artifactory. To move or copy the build artifacts select the target repository.

Gradle Release Management

The release management in Gradle relies on version (and other) properties managed by gradle.properties file. You add all the relevant properties to the release management configuration, and the plugin will read and modify those properties in the gradle.properties file.
These are the basic steps that the plugin performs:

1. Change the gradle.properties with release values (before the build starts)
2. Trigger the Gradle build (with optionally different tasks and options)
3. Commit/push changes to the tag (Subversion) or the release branch (Git)
4. Change the gradle.properties with next integration values
5. Commit/push changes to the trunk

Configuring Gradle Runners

The release management is also available for Gradle runners. To enable Gradle release management, edit the runner's step configuration and check the "Enable Artifactory release management" checkbox.

Staging a Gradle Release Build

Once the release management is enabled, the Artifactory Release Management tab will appear on the top end of the build page.

Clicking on the tab reveals configuration options for the release build:

The release staging tab displays the release and next development properties configured for the runner. The values are read from the gradle.properties file and calculation of the release and next integration version is attempted and displayed in the text fields.
If create VCS tag is checked (default), the plugin will commit/push the poms with the release version to the VCS system with the commit comment. When using Git, if 'Use release branch' is checked, the next release version changes will be done on the branch instead of the currently checkout branch.
The last section lets you change the target repository (the default is the release repository configured in Artifactory publisher) and optional staging comment which will be included in the build info deployed to Artifactory.
Click on the "Build and Release to Artifactory" button to trigger the release build.

Promoting a Release Build

Promotion is same as in RTD:Maven.

Working with Subversion

The release management supports Subversion SCM when using one checkout directory.
During the release the plugin will perform the following:

1. Commit the release version directly to the tag (if create tag is checked). The release version is not committed to the to the working branch.
2. Commit the next development version to the working branch

Working with Git

The project must perform source checkout on the agent side; if the build is configured to checkout on the server, the release plugin will modify the checkout configuration for the duration of the build and revert the change when the build is done.
The remote URL should allow Read+Write access.

During the release the plugin will perform the following:

1. If create branch is checked, create and switch to the release branch
2. Commit the release version to the current branch
3. Create a release tag
4. Push the changes
5. Switch to the checkout branch and commit the next development version
6. Push the next development version to the working branch

Note that changes will only be committed if changes were made to the files (pom files or gradle.properties).