nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to Group Fix Versions/Releases, or, how to identify releases to Testing

JTL105

Not sure if my group is in the 1% or the 99% regarding the software delivery process we follow. We make ~weekly drops from Development to Testing, then monthly those drops are combined and are released to Production. Due to our process we must be able to identify what content was in drop 1 to Testing vs. what was in drop 2 to Testing.

With no input on how we are "supposed" to use jira/specific fields we are using the Fix Version field to identify each drop from Development to Testing with a standard format.
2023.01.100 would be the first (100) drop to Test for the January 2023 (2023.01) release to production.
2023.01.200 would be the second (200) drop to Test, and so on.
From this I can use versionMatch("2023.01.*") to manually find all the content in the end January release to Production.

1.I'm looking at Structure/Advanced Roadmaps and from a reporting and status tracking perspective only the monthly Production release is relevant. Is there a way, using out of the box jira functionality, to group different/several Fix Versions together into one Release Boat (or into one Cardboard Box)?

2.Or, are we using Fix Version wrong? Is there a different field or other attribute hiding somewhere that we should be using to identify the different drops to Testing, so that the Fix Version field is only used for the monthly release to Production and we can use all the built in Fix Version/Release grouping functionality as it is intended?

Any suggestions or examples of how others identify and manage Fix Versions are appreciated.

Thanks, James

Accepted answers

Kit Friend

Hey!

You won't be alone but there's probably some approaches which will make things easier:

1) Advanced Roadmaps works by creating 'cross-project releases' which... cunningly... sit across projects - https://confluence.atlassian.com/jirasoftwareserver/releases-in-advanced-roadmaps-1044784195.html - you can use this functionality bundle together whatever combination of fixversions you want into a single release boat/box/your chosen metaphor - frequently this helps when you're communicating outwards to the business

2) You can tag multiple fixVersions to individual issues - this might help by enabling you to track a single thing as part of both the initial drop to test e.g. 2023.01.100 AND some sort of release boat e.g. JAN23_RELEASE - the metrics and reporting will allow you to use either of those fixVersions to query or collect things together

All comments

Kit Friend

Hey!

You won't be alone but there's probably some approaches which will make things easier:

JTL105

Thanks for the suggestions, I appreciate it.

I saw the Cross-Project Releases, but I'm hoping to avoid manually adding the Fix Versions into a group each month. As I explore further, I'm thinking that grouping by sprint might work better for my situation since the sprints are aligned with the monthly releases to Production.

Just FYI, I was not randomly making up metaphors. In "Plans" when I Group By Release each Release (Fix Version) is listed next to a boat icon. In "Structure" when I Group By Release each Release (Fix Version) is listed next to a cardboard box icon. I'm not sure why the same field is a boat in one type of view and is a box in another type of view.

Kit Friend

I liked the boats and boxes - you're right it's not very consistent as a UX though.

If your sprints work I'd definitely try that - best to keep things simple until there's a benefit to adding complexity

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server