How to configure deployment plan "After success build plan" trigger for all branches

[Manuel Mall]

We recently migrated to Bamboo 5.2.2 as we need the support for deployment from branches. We have a "default" deployment environment as per https://answers.atlassian.com/questions/224929/can-a-release-be-created-programatically so the release is created automatically when the relevant build plan completes. However, this only works for the master branch (we are using Git with automatic branch detection by Bamboo). Further looking into this it appears that the 5.2.2 deployment triggers do not allow to specify to fire "on any branch" but require a specific branch to be setup. This means although on the build side plan branches are automatically detected and configured in our deployment project we have to manually add/modify triggers each time a new branch from which we want to deploy is created.

Is there a better way of doing this? Why are deployment triggers always linked to specific branches? Can we have a trigger that fires when the build plan completes independent on which repository branch the build plan was run against?

[crakjm]

I also need to trigger a deployment plan based on a regex for branch name release/X.X.X, for all our staging environment. But I can only target master, any workaround ? 

The only way I found is to handle all the pre-production deployment inside the Build plan tasks

[Krisztian Springer]

Any new info here? I'm also looking for a solution.

[Gretchen]

I could be wrong but let's say you have five branches and three environments. It seems as though you wouldn't want more than one environment to be the recipient of more than one branch at any given time (and keeping developers from checking stuff into the wrong branch and accidentally triggering a deployment from an old branch is a risk). Furthermore you'd want to know absolutely which branch of code had the potential to be deployed to any given environment to avoid chaos. You'd risk overlaying newer code with older code if you had all branches enabled for deployment. And timing is an issue, when are you ready to deploy new code from a new branch to a particular environment. (There may be db or other independent factors that affect the timing and must be taken into consideration).

Look at it from a CM perspective rather than a developers perspective. The way I see it you wouldn't want to deploy from every branch as soon as the branch was created. You'd end up potentially switching back and forth on each deployment. The determination of which branch should be deployed to what environment and when, is something that can't necessarily be automated without someone's brain getting engaged when a new branch is created.

That said, you've accounted for that possibility in your build design by configuring the default "dummy" environment and set it up in such a way that the sort of chaos I've imagined is not possible. But I think your setup is more unique than not.

Whether it is possible that the Bamboo designers took that into account or not is a different issue and prompts the question from the other side of the fence, why would you let me create a configuration that could blow up my environment by overwriting with code from another branch without my authorization? It seems that they have prevented that by requiring the user to specify where they would like the build artifacts deployed.

I'd personally like to see more case studies (using complex examples) on how people are using deployments with branches, and more automation, to give a bit more clarity into how the folks at Atlassian envisioned this product being used.

Anyway, just my thoughts.

[xetius]

Our particular case study is relatively simple.

Our front end gets deployed to a Nginx server. The server is configured such that https://myserver.com/ serves the front end. 

When our devs are working on a new development feature, they create the feature branch from Jira, which ties it into Jira.  When that branch is committed, it deploys it to a location on the nginx server based off of the Jira ticket number.

As an example, let's take the Jira ticket "AB-123 Create new awesome feature"

At this point, Nginx is configured to serve the new content from the address https://ab123.myserver.com/, using the ticket number as the subdomain.  This neatly ties everything together.

Unfortunately, when deployments are tied to a single branch, this is not possible as the deployment does not get triggered for the feature branches.

We have other deployments for our server environments, where we deploy docker containers to our dev and test environments based off of the Jira ticket number.  Again, this does not work because of the single release branch.

I should be able to tie a regular expression, or wildcard of some sort to the branch selector to pick which branches are used for deployment.

[Manuel Mall]

Actually it appears what was suggested in https://answers.atlassian.com/questions/224929/can-a-release-be-created-programatically doesn't work at for branch deployments. Bamboo doesn't seem to honour the release numbering configuration setup when creating releases on running a deployment plan based on a branch. Instead it seems to be using the repository branch name as the release name although we have confgured the deployment plan to use a Bamboo variable as release name. It still works as in Bamboo 5.1 for deployments from master. This feels all very inconsistent (and breaks what we are trying to do).