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?
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?
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!
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:
Please include anything else you think would help while reading over these.
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.
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:
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.
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.
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.
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.
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)
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.
Let’s face it: most of us have too many meetings on our calendars. And few things are a bigger waste of time than recurring meetings that no longer provide any value to attendees (or the busines...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs