Bamboo with maven and gitflow

[Erates]

For a while now, I've been cracking my head on how to implement gitflow with maven into Bamboo, while not giving up Bamboo's great features like plan branches and deployment projects.

I'll sketch our environment first, before going to ask questions.

• The 'master' branch contains the latest version in production, so no SNAPSHOT version.
• The 'develop' branch is used for development. All feature branches branch from 'develop' and merge back into 'develop'. This branch runs on a SNAPSHOT version.
• The 'release/xxx' branch is branched from 'develop' and gets a -RCx version. So here, no SNAPSHOT anymore.
• We use Artifactory to store all our 'released' and SNAPSHOT jar files.

Because the jgitflow-release-plugin seems to be messed up and does things weirdly, we've written our own release plugin for maven. It basically has 3 goals:

1. start-release: creates a 'release/xxx' branch from 'develop' and sets the version to 'x.x.x-RC1'
2. bump-release: checks out the 'release/xxx' branch and bumps the -RCx version. (For example, from -RC1 to -RC2)
3. finish-release: checks out the 'release/xxx' branch, sets the version to x.x.x, merges to 'master', tags, updates the version 'release/xxx' branch to y.y.y and merges into develop.

This plugin works great, if you run it manually on your pc. But if I want to configure it on Bamboo, I seem to fail the configuration.

Here are a few of our requests:

• Automatically build and deploy (maven deploy to Artifactory) on a commit of the 'develop' and 'master' branch but not on the 'release/xxx', 'bugfix/xxx', 'feature/xxx' and 'hotfix/xxx' branches.
• Automatically build on the 'release/xxx' branch. With a manual stage we could do the 'bump-release' and 'deploy' goal.
• Manually start a release (so execute the 'finish-release' goal) without the need of bumping the version first.
• Allow one-click releases via JIRA.

We have tried using the default maven-release-plugin on a manual stage, and execute it only on the 'master' branch, but this updates the version to SNAPSHOT (which we don't want on the 'master' branch), and we are unable to use the -RC versions in the 'release/xxx' branches.

Ideally what we've been thinking, is that there should be the ability to 'override' branch configuration. So that one type of branch does Stage A, Stage B and Stage C, while other branches execute Stage A, Stage C and Stage D. Also, the ability to add 2 manual (only manual) stages which are executed in a XOR pattern. So first Stage A, then Stage B1 XOR Stage B2 and then back to Stage C.

So for the question, is there a way to configure our requests in Bamboo, without having to configure 3 different project plans and over complicating things?

[NullPointer]

Hi, 5 years have passed. Do you manage to implement something that made sense at the end? 

[Rich Duncan]

We've implemented something similar.  Although we're using Gradle, I'm very familiar with Maven.  So:

1. The release plugin is great when it fits your use case, but if you want it doesn't fit with your gitflow/release candidate approach, nor is it branch aware.
2. You can create a CI build with auto-created branch plans to do a 'clean install' on all of the work branches.
3. You need to create a release branch - looks like you have a plugin for that does as much of the are we ready to releae yet checking (e.g. no SNAPSHOT dependencies), and then creates the release branch
4. You have a bamboo plan that auto-creates branch plans to actually build release candidates.
5. That plan has a deployment project associated with it.  Then you can take the release candidate builds and deploy them to the various stages you have until you finally deploy to production.

HTH,

-Rich

[Erates]

Thanks, so in short, what you mean is we have 2 Plans. One that automatically creates plan branches for 'develop', 'bugfix/xxx', 'feature/xxx' and 'hotfix/xxx'. This plan branch has 1 stage, with 1 job that does a maven clean install.

The other plan auto creates plan branches for 'release/xxx' branches and has a deployment project associated. Does this plan branch do a maven clean install or does it also do the deploy? Does it get triggered by each commit? Because a release candidate version is associated with a release within maven, so doing 2 deploys (to the repository) will fail. The actual bump-version, does it get executed in the deployment project? The actual release (so the merge to master and tagging), where does that get executed?

Anyhow, even with these questions, it is a start to fix our problem