Linking deployments of release branches to Jira tasks

[Simone Chiaretta]

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:

1. I create a task, I work on it and I commit.
2. Bamboo build automatically and deploys automatically, and that build, which contains a commit linked to the task, shows it contains the task.
3. If I "promote" the same build also to test, then that release on TEST will show all the new jira tasks since the last time something was deployed on TEST.
4. Now I want to deploy to Staging. And for this I create a release branch, and I deploy to staging. Being this the first deploy coming from this branch, it doesn't show any task as included in the release. While it should.

Is this a bug of the Jira-Bamboo plugin? A misconfiguration of the plugin? or a missing feature?

Thx

Simone

[Marcin Oles]

Hi @Simone Chiaretta,

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.

Regards,
Marcin Oleś
Bamboo dev team

[Daniel Santos]

Hi @Simone Chiaretta

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.

[Simone Chiaretta]

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?

Thx 

Simone

[Daniel Santos]

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?

[Daniel Santos]

Hi @Simone Chiaretta

I'm chatting with a developer about your request and I want to check with you if the feature you think is missing is:

• the comparison between deployments of different branches
  OR
• the history of all changes since the branch was created (assuming there is no deployment for that branch before)

Can you confirm that for us?

[Simone Chiaretta]

Is comparisons between deployment on the same environment, regardless of from which branch they came from.. so more or less your first option.

[Simone Chiaretta]

@Daniel Santos , so you suggest that I should keep a "permanent" release branch, to which I merge commits from develop?

[Daniel Santos]

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.

[Daniel Santos]

I voted on @Marcin Oles question to make the life of other users coming to this question a little easier. Please share your remaining questions on that thread.