How to use a deployment project with multiple release branches?

[Michael Kolb]

We are using bamboo plan branches to do internal releases towards our testing team. E.g. there is a branch "release/tool-1.0", the next release branch will be named "release/tool-2.0" and so on...

The git branches matching the pattern "release/*" are build by a single build plan, that creates plan branches as soon as a new release branch appears.

I now got a bamboo deployment project to promote the internal releases to the testing team. Unfortunately I have to edit the deployment project every time there is a new release branch. The deployment project seems to be not aware of the plan branches feature.

So how to correctly use plan branches, without the need to manually edit the deployment project every single release? 

[Rich Duncan]

This is how we've addressed this problem:

1. Use a release naming pattern that uses the first (3) digits as the release number and the last digit as the release candidate number. 
2. Release Candidate Plan that creates plan branches for the pattern you specified
3. Assume we have an in-production release of 1.0.1 and a new release named 1.0.2 no builds have been done on that release.
4. The actual release version is determined by the release number and the current buildNumber on the plan branch so ${bamboo.releaseNumber}.${bamboo.buildNumber}
5. A hotfix is required on 1.0.1, the branch plan is run and builds successfully.  All of the artifacts have the appropriate release number and this number is used to 'create release' of the artifact - this part currently has to be manual due to a 'limitation' in the version number capability.  So, we 'create release' and provide the release number 1.0.1.8
6. Now this release is available to be deployed to any environment.
7. Similarly the first release build takes place for 1.0.2, the artifacts get the proper release version (1.0.2.1), we create the release with that version and the release is available to deploy to lower environments for testing

HTH,

-Rich