How does Gitflow releases work with Deployment projects?

So our suite of versions are Bamboo (5.3), JIRA (6.1.1), Stash (2.8.2). We are trying to leverage the intended workflow of these tools and apply them to our build/release workflow.

We have run into an issue trying to implement this:
http://blogs.atlassian.com/2013/05/version-management-jira-bamboo/

Our gitflow workflow goes something like:
- Create JIRA ticket (e.g. PROJ-123)
- Create feature branch from ticket
- Push changes (with "PROJ-123" in commit message)
- Merge into development branch
- Create release branch from development branch
- Create deployment release from release branch build
- Deploy release to Staging

So at this point (based on Atlassian documentation), I'm expecting the deployment status panel in PROJ-123 to contain the deployed details. But it does not.

Now I know this, if I were to push a change (with "PROJ-123" in commit message) into that release branch, I would get the result I expect in PROJ-123.

But the thing is, I'm already for a release after branching release from development -- I have no other changes to make at that point.

Were these tools not made to utilize the gitflow release workflow? Or am I missing something here???

1 answer

1 accepted

This widget could not be displayed.

Here's the problem: how Bamboo knows that PROJ-123 should be in while say PROJX-980 should be not ? All Bamboo knows about git branch is that it's a tip with certain parents. How far back in time Bamboo should look to collect changes is completely unknown. I admit Bamboo should be smarter in that regard but the best we can do is to try to find the point when you created the branch. In which case we would still not find PROJ-123 which happened before that.

The possible solution would be to have sth like 'custom range builds', I've opened an improvement request here: https://jira.atlassian.com/browse/BAM-14525. Please vote on it.

Since that is the intended behavior/workflow of Bamboo, then it doesn't align with the gitflow release model as advertised.

For the time being, it seems our workaround will have to be -
Create deployable release based on feature branch UNLESS there are new commits in the release branch, in which case, use the release branch...otherwise deployment information will not propagate to JIRA's deployment panel.

This would certainly work but feels a little clunky and not a workflow we can standardize for our dev teams.

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Published yesterday in Marketplace Apps

The 7 hacks of highly successful automation

...there's anything I've learnt from working, it's that people are lazy! No offense to anyone reading this, but it's true and we can all admit it. The easier you make something for someone, the more...

141 views 0 9
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you