How many plans are needed to handle standard gitflow branching strategy?

Question

I am implementing a CI project in bamboo using git / bitbucket / jira.

At the moment, I am trying to fit everything into one plan for building my project, handling release candidate, deployments etc.

I couldn't find any concrete example of how to implement a gitflow strategy in bamboo using plans, branching features, etc and would be great if I can have any pointers?

I did not want to have multiple plans because of maintenance but perhaps I would feel different about it if there was some kind of best practices around it which I am not able to find.

Could someone share their experience or what would be the best practices regarding bamboo plans?

Phill Pafford · Answer

What I've done in the past

* 1 plan to build all branches* if master branch, checkout latest tag, then build

* depending on how many environments you have, set up each one to have it's own deployment* DEV environment, this will auto deploy any successful develop branch builds
* QA environment, this will auto deploy any successful release* branch builds* to deploy the correct release branch we had to manually update the trigger to auto deploy the correct release
* NOTE: we removed the trigger that would auto deploy on successful build and manually did the release, we found this to be easier but it's not CI/CD

* PILOT/BETA environment, this will auto deploy any successful master branch builds* NOTE: since on the build we checkout the latest tag we need to rebuild the master branch after we push a new tag

* PROD environment, this is a manual deployment so we can deploy the correct build/tag/etc...

NOTE: any build artifact could be deployed to any environment, also we have dedicated QA and UAT teams for different environments