Have a question? Want to report an issue? Contact JFrog support

Skip to end of metadata
Go to start of metadata

Overview

Artifactory supports release management through the Bamboo Artifactory Plugin.

When you run your builds using  Maven or  Gradle with jobs that use  Subversion, Git or  Perforce as your version control system, you can 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 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.

When release management is enabled, the Artifactory release staging link appears on the top header bar in the job page.

Displaying the Release and Promotion Tab

To display the Artifactory Release & Promotion tab you need to click the small arrow indicated below.

 

Default Job

Release management tab moved from plugin version 1.7.0

From Bamboo Artifactory Plugin version 1.7.0, the Release Management tab was moved from the Plan page level to the Job page level because the process applies to artifacts in the context of a single job rather than a whole plan (which may hold several jobs).
The tab name was also changed from Artifactory Release management to Artifactory Release & Promotion.

Page Contents


Maven Release Management

The Bamboo Artifactory Plugin manages a release with Maven running the build only once using the following basic steps:

  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.

If the build fails, the plugin attempts to rollback the changes (both local and committed).

For more information including configuration of Maven Runners, and Jobs and staging a release build, please refer to Bamboo Artifactory Plugin

Configuring Maven Jobs

To enable release management in Maven jobs, edit the job configuration and check the Enable Artifactory release management checkbox.

 

 

Staging a Maven Release Build

Clicking on the release staging link opens a new page with configuration options for the release build:

Release Staging

The release staging page displays the last version built (the version tag is that of the root POM, and is taken from the last build that is not a release).  Most of the fields in the form are populated with 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 the Create VCS tag checkbox is checked (default), the plugin commits/pushes the POMs with the release version to the version control system with the commit comment. When using Git, there's also an option to create a release branch.

Click on the Build and Release to Artifactory button to trigger the release build.

Target server is Artifactory Pro?

If the target Artifactory server is a Pro edition, you can change the target repository, (the default is the release repository configured in Artifactory publisher) and add a staging comment which is included in the build info deployed to Artifactory.


Gradle Release Management

The Bamboo Artifactory Plugin supports release management when running builds with Gradle. This relies on the version property (and others) managed by the gradle.properties file. The plugin reads the properties from the Artifactory release management configuration, and modifies those properties in the gradle.properties file.

The plugin manages a release using the following basic steps:

  1. Modify properties in the gradle.properties to 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. Modify the gradle.properties to the next integration values.

  5. Commit/push changes to the trunk.

Configuring Gradle Jobs

To enable Gradle release management, edit the Artifactory Gradle Task configuration and check the Enable Release Management checkbox.

Staging a Gradle Release Build

Once release management is enabled, the Artifactory Release staging tab appears in the top header bar on the job page.

Clicking on the Release staging tab opens a new page with configuration options for the release build:

Gradle Release Staging

The Release staging tab displays the Release and Next development properties configured for the job. The plugin reads these values from the gradle.properties file and attempts to calculate and display Release and Next integration version in the text fields.

If Create VCS tag is checked (default), the plugin commits/pushes the POMs with the release version to the version control system with the commit comment. When using Git, if Use release branch is checked, the Next release version changes are carried out on the release branch instead of the current checkout branch. The final section allows you to change the target repository (the default is the release repository configured in Artifactory publisher) and an optional staging comment which includes the build info deployed to Artifactory.

Click on the Build and Release to Artifactory button to trigger the release build.


Promoting a Release Build

You can promote a release build after it completes successfully.

This is not a mandatory step but is very useful because it allows you to mark the build as released in Artifactory, and move or copy the built artifacts to another repository so they are available to other users.

To promote a build, browse to the build's result page and click the Artifactory Release & Promotion tab.

Artifactory Pro required

 Promotion features are only available with Artifactory Pro

Promoting a Release Build

Select the target status of the build ("Released" or "Rolled-Back"). You may also enter a comment to display in the build in Artifactory.

To move or copy the build artifacts, select the Target promotion repository.

Release management

From Bamboo Artifactory Plug-in version 1.7.0, the Artifactory Release Promotion was moved from the Artifactory tab to the new Artifactory Release & Promotion tab.


Working with Subversion

Release management with Bamboo Artifactory Plugin supports Subversion when using one checkout directory.

During the release the plugin does the following:

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

Working with Git

To work with Git, the Git plugin must be configured to build one branch AND to checkout to the same local branch.

The remote URL should allow Read+Write access.

The Bamboo Artifactory Plugin uses the Git client installed on the machine and uses its credentials to push back to the remote Git repository.

 Git ConfigurationGitHub Configuration

During the release, the plugin performs the following steps:

  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

Shallow Clones

Bamboo's Git plugin allows the use of shallow clones, however this causes the "push" not to work.

Therefore, when using the Artifactory Bamboo Plugin, you must have shallow clones unchecked.

For more information about shallow clones, please refer to git-clone Manual Page.


Working with Perforce

Release management with Bamboo Artifactory Plugin supports Perforce when using one checkout directory.

During the release the plugin does the following:

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

Changes

Changes are only committed if the files are modified (POM files or gradle.properties).

 

 

  • No labels