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

[Null]

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]

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