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

Skip to end of metadata
Go to start of metadata

Overview

The TeamCity Artifactory Plugin includes release management capabilities for Maven and Gradle runners that use Subversion, Git or Perforce for version control.

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 to which to deploy the release

  • Create a VCS tag for the release

Staged release builds can later be promoted or rolled-back, changing their release status in Artifactory, and build artifacts may optionally be moved to a different target repository.

Inside Artifactory, the history of all build status changes (staged, promoted, rolled-back, etc.) is recorded and displayed for full traceability.

Page Contents


Before Getting Started

Working with Git

Pre-requisites for using Release Management with Git:

  1. Since the Release Management process runs git commands, the git client must be installed on the TeamCity build agent, using an ssh key (using the git client with user and password is not supported)..
  2. The git client should be configured with an ssh key, so that it can access your Git repositories. Therefore, before running the Release Management process for the first time, it is recommended that you first make sure that you're able to perform a git push from the build agent console. Also, make sure that the git push command runs without displaying a user prompt. Note that configuring an ssh passphrase for the git client is not supported.

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

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.

Working with Subversion

Release management with TeamCity Artifactory Plug-in 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.

Maven Release Management

The TeamCity 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 TeamCity Artifactory Plugin

Configuring Maven Runners

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

Configuring Maven Runners

Staging a Maven Release Build

Once release management is enabled, the Artifactory Release Management tab appears at the top of the build page.

Artifactory Release Management Tab

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

Release Configuration Options

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.

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

Artifactory Pro Required

Promotion features are only available with Artifactory Pro

Promoting a Build

Clicking on the link will open the Release Promotion dialog:

Promote Dialog

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.


Gradle Release Management

The TeamCity 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 Runners

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

Configuring Gradle Runners

Staging a Gradle Release Build

Once release management is enabled, the Artifactory Release Management tab appears at the top of the build page.

Artifactory Release Management Tab

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

Gradle Release Configuration Options

The Release staging tab displays the Release and Next development properties configured for the runner. 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

Promotion is the same as in Promoting a Release Build for Maven.

 

  • No labels