A Simple Release Build

A simple release build can be performed by calling the following command on a project meeting the requirements:

mvn unleash:perform

This will trigger the goal perform of the unleash-maven-plugin which processes its underlying workflow step by step until the release artifacts are installed locally and deployed to the configured remote repository.

Project Requirements

• The project or, in case of a multi-module project, at least one of the project modules must have a SNAPSHOT version assigned to be releasable.
• The plugin must be configured in the project POM and the required SCM provider must be added to the plugin dependencies. The SCM provider implementation is dispatched by the developerConnection or connection string of the SCM section of your pom, scm:git:... indicates Git-based version control and requires the Git provider.

<project>
  ...
  <scm>
    <connection>scm:git:...</connection>
  </scm>
  ...
  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>com.itemis.maven.plugins</groupId>
          <artifactId>unleash-maven-plugin</artifactId>
          <version>1.0.0</version>
          <dependencies>
            <dependency>
              <groupId>com.itemis.maven.plugins</groupId>
              <artifactId>unleash-scm-provider-git</artifactId>
              <version>1.0.0</version>
            </dependency>
          </dependencies>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
</project>

What Happens

The perform goal has the following default workflow which is anchored in the plugin and can be overridden externally:

storeScmRevision
checkProjectVersions
checkParentVersions
checkDependencies
checkPlugins
checkPluginDependencies
prepareVersions
checkAether
setReleaseVersions
addSpyPlugin
buildReleaseArtifacts
removeSpyPlugin
checkForScmChanges
tagScm
detectReleaseArtifacts
setDevVersion
installArtifacts
deployArtifacts

This workflow splits up the release building and deployment into several tasks and orchestrates them in their logically correct order. Each step implements a small aspect of the whole process and is fully reversible. These are the basic steps that are done:

1. Check all necessary requirements at the beginning and fail fast in case of unmet requirements

• Are projects releasable (at least one module must have a SNAPSHOT version)
• SNAPSHOT parents are not allowed
• No SNAPSHOT dependencies or plugins are allowed
• Release artifacts must not be present in aether (remote repositories)

2. Set the release versions and build the project

• The project will be built only once and no additional SCM checkouts are performed
• Builds from your local working directory

3. Freeze the build in an SCM tag

• The release build sources and settings are frozen in a tag
• Tagging can also be performed if there are incoming remote commits if tagging from local working copy is enabled

4. Update the project for the next development cycle

• Sets the next development (SNAPSHOT) versions where necessary
• Commits the changed POMs to the current working branch
• Can also be performed on incoming remote commits, even if the remote commits change POM files. A builtin merge algorithm is able to determine the changes and update the POMs with the correct version before committing them.

5. Install and deploy the artifacts at the very end

• Since the deployment of the release artifacts is not reversible it is performed at the very end of the workflow
• If anything goes wrong before deploying the aritfacts this step is never triggered.

Rollback In Case Of An Error

One key concept of this plugin is to implement the whole release process in a way to be fully reversible. If an error occurs the rollback of the whole workflow is triggered automatically and the project and any external resources such as the SCM, the local and remote repository, ... should be in the same state as before the release build.

If f.i. the step buildReleaseArtifacts fails all steps that have been executed until this step are rolled back in their reverse order. This partial rollback workflow would then look like this:

[x] buildReleaseArtifacts
[x] addSpyPlugin
[x] setReleaseVersions
[o] checkAether
[o] prepareVersions
[o] checkPluginDependencies
[o] checkPlugins
[o] checkDependencies
[o] checkParentVersions
[o] checkProjectVersions
[o] storeScmRevision

In order to visualize what is exectued during the rollback there are markers prepended to the step ids. [x] means that the step offers a rollback method that will be executed while [o] means that this step doesn't provide a rollback method. This is often not necessary since many steps do not change any resources but only perform checks.