2

My development team and I have been using release dates (or fixVersions as they are called in JIRA) to keep track of all tickets for our iterative development schedule.

However, as our team grows this is becoming increasingly complicated. Some tickets need to have code deployed to be considered "done" whereas others (mockups, plugin changes etc.) do not. When attempting to deploy a fixVersion we only want our deployment specialist to see tickets with deployable code. However, we do not want to lose track of tickets completed from the same sprint that do not have code to be deployed.

Has anyone else struggled to make this organizational distinction in JIRA? What is the best way to approach this?

  • I believe the discussion on how to name a Jira release might help you out. – Tiago Cardoso Mar 26 '18 at 23:30
  • Do you mean you need some kind of authorization to let particular people to see only specific types of tickets in a release? – Alexey R. Mar 27 '18 at 19:28
  • @AlexeyR. it has more to do with organization than authorization. Aka do people use labels to signify what was released vs what was considered finished with out deployment, or perhaps different ticket types? – Sasha Mar 27 '18 at 22:00
  • @TiagoCardoso than you for that! That link is very helpful. – Sasha Mar 27 '18 at 22:01
3

This is normally addressed with resolutions. In your case you need to have the following resolutions configured:

  • Released - Deploy Required.
  • Released - Deploy Not Required.

So the person who is going to handle the tasks will use the filter like this:

project    = "Sample Project" 
  and 
fixVersion = "Release.2018.03" 
  and 
resolution = "Released - Deploy Required"

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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