5

I'd like to find the best way to manage releases using Maven 2, Bamboo 3.1 and JIRA 4.3. I've tried many things but I keep hitting dead ends due to bugs or missing functionality.

My end goal is to have versions come from JIRA, have Bamboo take those versions and build artefacts from them using Maven then deploy those artefacts to a repository (Nexus in our case).

Here are the approaches I have tried:

1) Use a place holder in all poms for project versions:

Parent pom

<project ...>
  <groupId>group</groupId>
  <artifactId>parent</artifactId>
  <version>${ci.version}</version>
  ...
  <modules>...</modules>
</project>

Child pom

<project ...>
  <parent>
    <groupId>group</groupId>
    <artifactId>parent</artifactId>
    <version>${ci.version}</version>
  </parent>
  <artifactId>child</artifactId>
  ...
</project>

This builds if you start the build from the project root pom and specify -Dci.version=<my-version> on the command line. Combine this with the Bamboo Release Management Plugin and I can build and deploy versions of my modules and release as needed.

The problem with this approach is that Maven does not replace place holder variables in poms when deploying or installing which means the poms in the repository have the ${ci.version} marker when I'd really like them to have the concrete version. Because of the place holder it means nobody can use the modules I deploy. See MNG-2971.

2) Use concrete SNAPSHOT versions in the pom and configure bamboo to execute the Maven Release Plugin using the Bamboo Release Management Plugin.

Unfortunately the Maven Release Plugin needs the version to increment to, the bamboo plugin allow you to get the name of the current version to build but not the next one. Without this information using the Maven Release Plugin would increment the version to something that is not managed by JIRA. To make this option work I'd either need the next version available to me or be able to run a plan after the Bamboo Release Management Plugin has done it's thing (this second fix would also add extra mess to the commit logs as you'd get one commit for the auto increment and one for the proper increment).

2.b) Same as 2) but you have to specify the next version in Bamboo before any release build through the plan configuration interface, setting the value manually to the next JIRA version the plan should be working on. This fixes the problem with 2) but adds extra manual steps.

3) Do things manually, probably using the Maven Release Plugin. Completely ignore all release functionality in Bamboo and manually manage released on the command line by calling the Maven Release Plugin goal to change the version as and when needed. JIRA versions will also need to be released manually when this happens. We also need to configure a bamboo build to run and test the tag that the release plugin creates for the non-SNAPSHOT version.

This option has so much process involved something is bound to go wrong.

I can't be the only person trying to get automated releases using these technologies, can anyone help.

Thanks

Matt
  • 722
  • 10
  • 20

1 Answers1

0

matt,

You have to specify in your goal -Dci.version={bamboo.custom.brmp.name} I stumbled upon your question when I was looking for exact the same information, but then for JIRA 4.4 and Bamboo 3.3, where the release management plugin has been replaced / upgraded with the JIRA Bamboo plugin ...

Hope this helps,

Francis

Francis Martens
  • 3,458
  • 4
  • 24
  • 26
  • Thanks for the response. It turns out that this approach doesn't work for reusable components outside of the project because while the correct version of an artefact will be deployed the pom ends up with the place holder instead of the concrete version. So parent references have ${ci.version} making the poms unusable outside of the parent project. In the end I went for a combinations of fixed snapshot version and the maven versions plugin called explicitly from a bamboo job to change the version to what is needed. – Matt Dec 19 '11 at 10:34