What I want to achieve is tracking to which environment a jira issue is deployed.
This works fine when I always deploy from the same branch in Git, but is not working when I deploy starting from a branch.
Let me explain with an example:
Is this a bug of the Jira-Bamboo plugin? A misconfiguration of the plugin? or a missing feature?
In current shape, Bamboo does not support comparison of two versions created from different plan branches. This problem also affects two versions deployed on a single environment.
This is due to the way how Bamboo calculates the diff (in commits, in Jira issues, etc.). We rely on partial diffs from build result history.
Each build result introduces a chunk of the diff (1 commit, 1 issue, for example). If we want to compare builds 1 and 10, we just add up all the changes. And since each deployment version must be based on some build result, it's possible to tell how many build results happened in between two versions, and hence it's possible to calculate the diff.
For two separate plan branches, we are not able to calculate the diff in the way it's done now, as they are divergent (no common ancestor in Bamboo build history). So if you create two deployment versions from build results which are not from the same plan branch, Bamboo can't calculate the diff for you.
However, we're open to accepting improvement requests. One possible improvement request could be for Bamboo to calculate diff based on e.g. the Git log, and to stop relying on in-between build results. You can create the improvement under jira.atlassian.com/projects/BAM.
On another note: maintaining a single release brach may be an option for you, if you would like to workaround the problem. If you'd like to use the Git workflow, to my understanding, it assumes that there's a `master` branch which contains all the releases. (The ad-hoc release branches are ephemeral, after all.) Maybe this would help you.
Bamboo dev team
This is expected behavior, it happens because the deployment list of contents is created based on a difference between the last deployment and the current one for the same branch. If there is no prior deployment for that branch, Bamboo won't be able to know what commits and tasks are part of that release.
The same behavior can be observed for plan builds. The first build of a branch will not list the commits or tasks due to the same reason. It needs to know what was part of the previous build to be able to list what is part of the latest one.
I've created the following feature request to report your need for this: [BAM-20341] First deployment of a branch should list commits and Jira linked content.
Please let me know If that makes sense to you.
Thank you for the answer @Daniel Santos .
It seems strange to see this behaviour since Atlassian recommendation is to use gitflow, which dictates that production releases are done from an ad-hoc release branch.
What workaround would you suggest so that jira tasks are linked correctly to release that come from a release branch?
I'll work on getting someone from Bamboo design to answer this one. The Bamboo devs are located in Gdansk and will only be able to help us tomorrow. In the meantime, I'll share what my understanding is.
You may have a release branch where you can run all your builds and iterate over it when testing each new feature added, but when the whole content of a release is added and tested you are able to merge it into a master branch or a platform branch which will be the one deployed. Using this approach you would have just a few branches that would be handling the stable version of your application. Those are the branches you will deploy often, therefore avoiding the issue mentioned.
Does it make sense to you?
I'm chatting with a developer about your request and I want to check with you if the feature you think is missing is:
Can you confirm that for us?
As I shared before and @Marcin Oles confirmed in his answer below, you should use the release branches ephemerally. Deploying from a master or any other permanent branch of your choice would solve the issue. So once your release is done you can merge it to a permanent branch and deploy from it.
We’re excited to invite you to this action-packed webinar where we will demonstrate how to integrate Opsgenie’s powerful alerting and on-call management tools with your entire Atlassian stack. Mar...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs