04/28/2015 by Daniel Huchthausen in Software Craftsmanship

Automated Release Management

Use SCM-Manager Universe to implement an automated release-management for your projects. You can do that by using Jenkins and Sonatype Nexus. In this post we will show the necessary configuration for Maven projects with an automated deploy of snapshots and release of new versions.

Purpose of automated deployments

Automating the deployment of your projects to Sonatype Nexus has 2 major benefits.

• By automating the deployment of releases you are ensuring the documentation of the projects releases.
• By automating the deployment of snapshots you are ensuring that all developers can always use the latest dependencies.

Deploy snapshot to Nexus Repository

The described process will deploy a snapshot version to Sonatype Nexus each time it is built successfully with Jenkins. The release of a new version will automatically adjust the version number of the project and create a new snapshot with an incremented version number. This leads to 2 commits to the repository.

Prerequisites for automated release managements

The implementation of this process requires 2 plugins for Jenkins:

• Maven release plugin
• Config file provider plugin

Aside from those plugins there are only a few modifications to the pom.xml and to the Jenkins job configuration necessary.

Maven Configuration – pom.xml

For the implementation of the automated release process it is necessary to add the following 4 sections to the pom.xml:

• scm – information about the repository connection
• build – used plugins
• distributionManagement – information about the release destination
• repositories – location of your dependencies

SCM Section

This section contains the information about the location of the repository. Normally you need three connection types here:

• developerConnection: Used to check in the new version after a release. This connection requires write access.
• connection: Used to check out the sources for the release. Requires at least read permissions.
• url: Connection for web calls.

Build Section

Here you have to provide the information about the required Maven plugins.

DistributionManagement Section

In order to release new versions automatically it is necessary to provide the name and the location of the target locations in Sonatype Nexus for the snapshot and the release versions.

Repositories Section

If you want to use the latest snapshot version for each build you can configure an update policy for the snapshot repository. If you don’t provide a value for the update policy the default value is never. Jenkins Configuration

• Job configuration:

  • Build section: clean deploy (each snapshot version gets deployed to Nexus)

  • In the section Build Environment you need to enable two option: Provide configuration files and Maven release options. The configuration file is required for the usage of a settings.xml in Jenkins, the other option enables release builds.

  • By checking the option Maven release builds you enable the possibility of manually starting Maven releases for the project.

  • Deployments of snapshots will be performed automatically and releases of versions will only be perfomed after they were started manually.
  • Build-Triggers section: select poll scm (each change to repository gets build)
• settings.xml configuration
  • The managed files plugin for Jenkins allows you to configure centrally managed files like the settings.xml. This file is mainly required to configure the credentials to access Sonatype Nexus. To create a settings.xml navigate to the “Jenkins → Configure Jenkins → Managed files” screen. If there is no settings.xml available you can create a new one. It is necessary that the ServerId is identical to server id in the pom.xml. The setttings configured in this file are being merged with the settings of the executed build job. This will be done if you configured the file in the settings of your jobs, in the section Build Environment.

Advantages of automated release management

By implementing the automated release process for snapshots and new releases of your projects you ensure that the sources are always up to date. Hence all developers can rely on the fact that the dependencies they use are up to date. Besides that you automate the release-management for your projects. Of course you will have to find a policy of deleting expendable snapshot releases, otherwise you will have tons of data of old snapshots.

---