3

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?

4
  • I believe the discussion on how to name a Jira release might help you out. Commented Mar 26, 2018 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.
    Commented Mar 27, 2018 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
    Commented Mar 27, 2018 at 22:00
  • @TiagoCardoso than you for that! That link is very helpful.
    – Sasha
    Commented Mar 27, 2018 at 22:01

1 Answer 1

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"
0

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.