Doing Maven releases when releasing a version in Jira (also: how to roll-back)

[Jules Alberts]

Hello everyone,

First, this is how we are setup: we have Jira with the agile (scrum) plugin, Bamboo (+ Fecru, Confluence) and our software is in several Mercurial repositories. So, what we could have is a version that looks like this:

• OurSoftware 2.1.1
  • OurProjectA 3.0.0
  • OurProjectB 1.0.1

Currently, when someone commits to the default branch of a repo, Bamboo will start a build and deploy that project to the Testing servers of our TAP street. There is no version being release, only build, test, deploy. Releasing a version to Acceptation and Production servers is done manually:

• create a version in Jira, tag the tickets
• go through the Jira tickets and see what tickets are tagged with the version
• see which software projects are hit by those tickets (we comment our Mercurial commits with the Jira ticket number, so Fecru will allow us to see which commits have been done related to that ticket)
• do a Maven release:prepare and release:perform on each project that should be in the version. Depending on what has been done, we do a major, minor or bugfix release
• inform sysops which version of which which projects should be deployed to which servers
• deploy is then done manually

What I would like to have is something like this:

• create a version in Jira, tag the tickets
• release that version. For each project that is related to the tickets of this version it should fire a Bamboo build plan
• when all these plans have succeeded a Maven release:prepare and release:perform will be done. The Jira version type (major, minor, bugfix) should reflect in the Maven releases. So, if OurSoftware 2.2.0 is released, we should get these versions:
  • OurSoftware 2.2.0
    • OurProjectA 3.1.0
    • OurProjectB 1.1.0
• if anything goes wrong, do a rollback
• if all goes well, two manual Bamboo Stages should be available that will deploy to the Acceptation and Production servers.

 So, in all this, the only manual steps are: release the version in Jira. Deploy to Acceptation. Deploy to Production.

 There are a few things I'm wondering about:

• how could I automate the Maven version numbering?
• if on OurProjectB the release:perform fails, ideally OurProjectB should be rolled-back to 1.0.1 and OurProjectA to 3.0.0. But, the changes made have already been committed to Mercurial and the Artifact of OurProjectA has been uploaded to our Artifactory. How would I revert these steps?

 Quite a long story :) I'm interested in how other people solve this. TIA!

[Chris Johnston]

We do something similar.  In Bamboo -- we have release build plans that are designed to be triggered from clicking the release button in Jira.

These build plans are separate from the nightly / dev build plans.

In the release builds plans, we have a custom script tasks that makes sure $bamboo.jira_version variable is set (this implies it was kicked off from Jira).  If it is not set, then it fails the build.  If it is, it continues.

We then have another script task which parses out this variable and uses it to do things like merge our release branch, change the maven pom file to the right build, do the build, etc.

[Jules Alberts]

Thanks Chris. How do you deal with versioning of the projects that are in a release? Do they all have the same version ($bamboo.jira_version) ? We often have releases where project A has fixes/new functionality but project B hasn't, and in that case project B's version shouldn't change.

[Chris Johnston]

In our case, we have 1 jira project that corresponds to an end-customer project.  Within that project we can have N number of repositories -- each being it's own software product.

Because of this -- we use a naming convention in our versions.  So for example, if we have a product called ABC, then we have versions in jira like this:  ABC_1.0.0, ABC_1.0.1, ABC_2.0.0, etc.

We have a release build job for each product (eg, ABC).  When a release is triggered on ABC_2.0.0 the build job parses out the version string to use in the build (for example, if it's a maven job, it fixes the version in the various POMs, merges the correct release branch, sets the commit tag at the end, etc). 

If ABC has a dependency on XYZ 1.5, then it is expected that by the time we do a release in jira, that dependency is already properly set -- our releases are already tested at this point in their integration branches, so this is always true.