We are a web SaaS company using gitflow and JIRA. As we are 'done' (QA approved) with a feature, we move the story/ticket forward in Jira to a 'done' status. At that point we wait until it gets approved for release which means a developer merges that to develop and will get assigned a fixVersion in JIRA. As bugs are finished, they also get assigned a fixversion.

That means, in theory, all the tickets in a fixversion should match what is on develop and if a release branch is made, it would match perfectly.

However, in practice, we find that of course people forget to add tickets to a fixversion, or the ticket status wasn't moved forward but was merged, etc. So we have tickets that are in a JIRA fixversion that are expected to be released, but are still on a branch, and other tickets that are committed and will get released, but aren't expected to. This forces a developer prepping the release to manually check commit messages to confirm each ticket is in fact represented and there aren't some missing. This is manual and quite time-consuming.

Are there tools or integrations or anything that would solve this problem? Or a process change (of course, I can tell people to do a better job, but manual processes will always fail at some point).

I've started building my own tool using JIRA and Bitbucket (or github) API's to do that match automatically, but would love to find someone who already has solved this problem.

1 Answer 1


You should test the development branch rather than the feature branch.

You only know if a feature works after its been merged with the other features in a release.

Obviously you can also test the feature branch to make sure its finished prior to merging. But the main QA needs to be done on development or a release branch.

Now instead of testing and keeping track of individual features and bug fixes, you are testing a version of the software with a set list of changes in it. You will know during testing what version each feature has and not have this disconnect between finishing and 'approved of release'

Also, ensure you feature branches include the JIRA ticket number, then you will be able to link their merge with the ticket.

  • We test on both the feature and release branch, yes, but that's not relevant to the question. There is always the possibility someone forgot to update the JIRA ticket version after merging, so the new code is there, but didn't get tested and was released anyway. Or expecting the change, but it not working (cause it wasn't merged). That one we catch, but is tedious to fix. We do use the ticket number for the branch name. Nov 17, 2018 at 1:01
  • its possible, but highly unlikely as you set the version at the begining of the sprint and cant say you've finished untill its tested. So three different people have to not notice for a whole week while they work on the ticket. even then its a simple fix to compare the merge commits with the ticket numbers and update the ticket.
    – Ewan
    Nov 17, 2018 at 5:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.