nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Bamboo Plan Best Practices with GitFlow

Jimmy Petrus

Greetings,

Consider I have a project with GitFlow branching model:

master
hotfix
- 1.2
release
- 1.0
- 2.0
develop
- feature 1
- feature 2

How should I configure my Bamboo plan to accomodate the above project? Can I just create one plan for all? Or should I create 4 plans? Ideally, definitely I want to be able to create only a single plan for one project.

Of course, I'm aware about plan branches, but it seems to support only one child branch. To support the above GitFlow branch model in one single plan, I'll need to setup the plan branches in hierarchical (nested children) branch model. Can I setup hierarchical branch model in a plan? Or am I missing something?

Possibly there are other more elegant ways to configure the build plan for above project without plan branches -- I'll welcome any feedback and suggestions.

If the solution with one Bamboo plan is possible, I'd prefer an answer in step-by-step and concise manner.

Note that I have read https://answers.atlassian.com/questions/263545/how-to-setup-bamboo-for-gitflow-branch-build-plans, but it doesn't answer my question clearly yet.

Experts out there, please advise! Thanks!

Accepted answers

All comments

Jason Monsorno2

4 plans definitely looks cleaner, but it matters what you're trying to get out of it. If all you want is builds, testing, and e-mail alerts then 1 plan would make sense and with GIT can be done. 4 plans add complexity for maintainability as you have 4 separate configurations and 80-100% of it is identical so most changes have to be performed 3 more times, but probably simplier for end users.

4 plan approach is more set and forget where someone new could easily pick it up, building in conditional deployment statements like I remark on in the linked question is more like the "job security" approach because if you don't document the how and why to it noone else will touch it which typically screams poor maintainability.

Pros & cons exist for both or any hybrid, I suggest you play around and see want you'd be willing to maintain long term.

Jimmy Petrus

Hi Jason, thanks for your reply.

Assuming that our users are advanced enough, and that we can go with 1 plan. How do I set it up with Bamboo?

I just want to make sure that we leveraged every Bamboo's features in the best way possible. And that's what the industry used the most.

Let's take it the easy way, consider the above GitFlow project example is your own project, how would you configure your Bamboo plan?

Thanks again for your help -- really appreciated!

Jimmy Petrus

Hi Jason, thanks for your reply.

Assuming that our users are advanced enough, and that we can go with 1 plan. How do I set it up with Bamboo?

I just want to make sure that we leveraged every Bamboo's features in the best way possible. And that's what the industry used the most.

Let's take it the easy way, consider the above GitFlow project example is your own project, how would you configure your Bamboo plan?

Thanks again for your help -- really appreciated!

Jimmy Petrus

Hi Jason, thanks for your reply.

Assuming that our users are advanced enough, and that we can go with 1 plan. How do I set it up with Bamboo?

I just want to make sure that we leveraged every Bamboo's features in the best way possible. And that's what the industry used the most.

Let's take it the easy way, consider the above GitFlow project example is your own project, how would you configure your Bamboo plan?

Thanks again for your help -- really appreciated!

Jason Monsorno2

I'm still playing with it, we use SVN and GIT on different teams and one of the GIT teams is using GIT Flow and are transistioning to Bamboo so right now it's like playing stocks with fake money, I'm doing it but it doesn't really matter yet. What I've got right now is 2 plans per repo, master and develop. The master plan looks for ^release* branches and develop looks for ^((feature)|(hotfix))* branches. The release branches aren't tags but ours end up having little to no changes and master obviously gets changed but isn't actively developed like it's supposed to be so that gives me less changes on that plan which I'm trying to add nightly smoke tests to but haven't got that situated yet. The develop plan and its branches are a bit more active, I keep debating about where to put the hotfix branches but currently they're on this side.

All the developers use command line git and we aren't using anything to assist in enforcing git flow outside of Bamboo so the develop plan has a Deployment project with no trigger (manual) which will create a release branch for us and master plan has a Deployment project which verifies develop has the merge, deletes the merge source branch, and tags master; I like it separated from the code here because it verifies a successful build and unit tests before tagging.

I'll probably have more changes but that's what I've got so far.

Jimmy Petrus

Thanks for your insight Jason, really appreciated.

I'll try to setup a single plan and put the rest as plan branches, and see how it goes.

Aakash Basnet

we are also using a same git flow branching model and for that I am thinking of configuring a single build plan but with a create branch plan enabled. I hope single build plan with plan branch will works well to meet our reqiuirements.

If you guys thinks that it doesn't work or is not a good practice kindly request you to provide the suggestio.

Thank you

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bamboo

bamboo-administration