How to setup Bamboo for GitFlow branch build plans

[James Barwick]

I've read all the documentation (I could find). Nothing tells me 'HOW' to setup Bamboo to most effectively use Git-Flow branching. Yes, I read the documentation on how to enable Bamboo banchn plan auto-create.

The quetions are: Should I?

And, HOW?

Do I auto-enable Push Merge?

Should the merges come from 'master'?

Should the merges come from 'develop'?

Should the build plan merge then push to 'master'?

what should the regular expression in the build plan be? The example in the documentation (branch1/branch2/branch3).* was not helpful. What are branch1 and branch2 and branch3 supposed to be?

[Jason Monsorno]

We don't use Git Flow specifically but a similar setup so I'm taking pieces that I know work and some ideas that should work, cum grano salis.

• The flat approach:

One plan per repository, plan set to master and no regex for branches. You'll need to add any existing branches once to have the plan catch up to where your repo is at, it only finds new branches.

Most builds I come across are rather simply and cannot be resumed if there is a failure so I like to make all my steps inside of one stage with one job with multiple tasks. This removes the overhead of having artifacts piling up and the latency in storage and retrieving/copying the same data multiple times. I can't preform any concurrency in my builds or testing so the big downside I have is it's all one log but I only reference the log on failures anyways.

If you want to get the most of your CI tool then I'd have it do deployments as well, this is where the flat approach can get complicated quickly. All your plan and plan branches share a build configuration so you have to have them all go through a deployment task and then decide if you want to deploy it inside of that; ex. deploying only 'develop' and 'hotfix' branches (I'm saving master for something special) and not deploying each features branch. Deployment tasks on branches has a fuzzy future at best right now so I'd slap all of that into the normal build workflow.

The master plan! Like noted earlier, this shares the same build workflow as the branches; personally I like it being the only one that cares about the artifact so all the builds generate an artifact but if branch=master it's not empty. The plan/master build will have a deployment project associated with it, that will have the deployment steps and environment for your functional testing. We have a 3 stage deployment, a.k.a. 3 environments; functional, promoted, production. Function has a trigger on successful plan which hopefully means on every commit, that deploys to our first level testing site where people verify simple integration. Promotion is manual and deploys to our second level testing site as well as tags that revision (we use a Bamboo global variable to control the tag/release name), testing at this level includes deeper integration, regression, and load testing. Then finally producton deploys to production and increments the Bamboo Variable version (still working on that). Using the artifact through both levels of testing and production helps ensure that I won't have some wonky build issue for production, the tags remain as milestones in time that ideally don't need to be built.

• The two stem approach:

Fairly similar but pulls out 'develop' and anything else you want like 'hotfix'

First plan per repo, plan set to master 'feature/*' regex to only grab feature branches - use can also write to regex as an except so you can not pickup 'develop', 'hotfix', etc and not need to explicitly label feature branches with 'feature/'. Same setup except no deployment task in build workflow. The plan/master build will have the same deployment project as before.

Second plan per repo, plan set to 'develop' and regex used to ignore features branches. Since these are now separated in their own plan, they can include deployment steps without as much confusion and can include a manual stage to handle the merge (beware, you can trigger manual stages from previous builds which could cause complications)

'develop' now being the plan instead of a plan branch could also have it's own deployment project, this could also provide a safer option to the manual stage for merging.

[James Barwick]

I get all that. Thanks. I appriciate hearing stories of how other do it.

as far as multiple stages deployments...not even on stage 1 yet, so can't go multiple. I just want to run unit tests. I have created a 'deployment' project and an SCP job, but have yet to get an artifact out of Bamboo.

What I want to do is extremely simple.

I want master to be the branch where I tag 'versions' (I don't think I need to branch a version...if I do, can always decide later)

I want release to be the branch where I QA

I want hotfix to be the branch off of master

I want develop to be where we do changes and commit featuers

I want feature to be branch(es) for features.

The above "I wants" are based on my understanding of GitFlow features in SmartGit or SourceTree for 'create feature branch' 'complete feature branch' 'create hotfix' etc. We will never use git command line (never say never).

But using Git or GitFlow is not the question.

The question is: How to setup Bamboo branching? Auto, manually specifying all branches, do you enable merging, etc..etc??

When I finally make it, maybe I'll post how I did it. 3 weeks now...nothing. No ROI. 10 days left before I either show ROI, or abandon the project and just go back to hudson and subversion. (and of course I wont have Bamboo features...but my boss don't care if there's no ROI)

[Jason Monsorno]

I'm under the strong belief that merging should be manual. If you have any hope of not letting managing Bamboo control your day, I'd make branching automatic. We have branches expire at 30 days incase of inactivity but not deletion, on a 14 day sprint cycle the only false positives we could have are untouched epics which we haven't had occur yet.

[Jason Monsorno]

Advice you want, advice you shall receive. I prefer to custom fit solutions to existing structures than redesign structures to fit the cookie cutter solution.

[James Barwick]

Ron Chan,

Thank you for pointing out this blog. I think I've come across all of that information before.

However, it still doesn't tell me how to setup Bamboo to deal with the branches.

How to setup a deployment project?

which build plans should target which branches?

which build plans should be manual build versus auto build?

It is possibe to 'merge to master' or another branch if the plan branch succeeds (which is implied in the options for merge commit).

Or, perhaps I haven't read the blog you pointed out carefully enough.

[James Barwick]

I absolutely have to disagree with you with one exception: "Assume alot"

I WANT you to assume a lot. I want to know what I should do! So assume a "generic" GitFlow project with a master, develop, feature, release, and optional integration branch and tell me how I should setup Bamboo.

So here is the answer to your questions:

• Do you(or want to) use Bamboo to deploy or just build, does that include production
  • I don't know.. you tell me. Why don't you assume I want to include production. If I don't, then I'll omit those steps myself. Give me a complegte solution.
• Do you deploy branches or just build and run tests on them
  • Again, assume I deploy branches. I would assume that running a build and tests is simple. Show me the hard stuff. Again, if I don't want to do it, I'll omit those steps.
• Are you interested in building/deploying tags
  • Should I be? I dont' know. You tell me. Show me how to build and deploy using tags. Give me the setup and configuration steps. If I don't want to do it, I'll omit those steps.
• Why do you want to enable automatic merges and on what criteria
  • I don't know. You tell me. Why is the feature there? There has to be a reason. If the reason is explained, I'll know if I want to do it or not. What is the best practice? Should people paln on doing merge builds?
• With your release structure, does every sprint/iteration get released or do they stack up first
  • Does this matter at this level? Maybe I will. Maybe I wont. Again, I don't know. So I would love some examples.
• What are you trying to use the branch REGEX for, what branches are you trying to filter in or out
  • I don't know. What should I do? Use them or not? do I want to build all branches? How do I do that? Do I really need to create a "plan branch"? Or do I misunderstand what a 'plan branch' is?

continue......

[James Barwick]

....continued

I think there are a bunch of really really smart folks out there that use GitFlow and there should be a set of recommendations at least at a very basic level.

Learning by example is much more valuable than:

There is this option for filtering branches with a regex: (branch1|branch2|branch3)./* when I don't even know if I should or should not populate this box.

Based on about no less than 6 GitFlow presentations and video's that I've watched the say:

* the 'master' branch is what goes into production

* The 'hotfix' branch will branch off master for production fixes and merge to 'develop' and 'master' (double merge/commit)

* the 'release' branch is where you might do QA (with merges to 'develop' if there were fixes and then 'master')

* the 'integration' branch is where you might do big merges

* the 'develop' branch is where you keep a current development version

* the 'feature' branch is where you develop the feature (and there can be dozens of these)

So, if I create 'feature' branches or in some video's 'branch per issue' (broadly calling an issue a feature) how would I setup bamboo to effectively 'choose' these to build?

Sorry for the long rant..I don't mean to be harsh to you specifically. Not at all. I thank you for any help you can provide. I'm just frustrated that I can't find any documenation to tell me what to do beyond listing all of the switches and buttons.

[Jason Monsorno]

I'd like to get more details on what you want first than try and give examples on how I would implement it.

As asked this is impossible to answer without being vague in return or assuming alot. Git-Flow has a few different well defined ways to implement it and like saying any Agile method most people put their own little twist on things so now including Bamboo to fit what you want to do makes even more options.

Some specific details that would be helpful are:

• Do you(or want to) use Bamboo to deploy or just build, does that include production
• Do you deploy branches or just build and run tests on them
• Are you interested in building/deploying tags
• Why do you want to enable automatic merges and on what criteria
• With your release structure, does every sprint/iteration get released or do they stack up first
• What are you trying to use the branch REGEX for, what branches are you trying to filter in or out

Please include anything else you think would help while reading over these.

[Ron Chan]

James,

I couldn't agree with you more. There's no reason for Atlassian not to have clear documenation of all these Bamboo features and best practices on how to best use them. I've mostly learned and understood much of how Bamboo works through sheer trial and error.

Saying that, there is something I came across that has somewhat helped with Bamboo's "git flow" in relation to the "GitFlow" workflow. https://answers.atlassian.com/questions/220237/stash-branching-model-vs-git-flow

This should help!