Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,461,569
Community Members
 
Community Events
176
Community Groups

Bamboo with maven and gitflow

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?

2 answers

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

0 votes

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

 

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 wink

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events