Hello,
Thanks in advance for any comments (nice ones please, this isn't Twitter!). I have a general question regarding managing the builds and versions that sprint items are being released in.
The following is an example of how we work 'in real life', and I'm trying to work out the best way to use Jira for this. We produce a series of interm testing builds/versions until a sprint is completed and then a final customer release build/version. It may go something like this:
My question is, what should I do with all these builds in Jira? Currently, each time we produce an interim build for testing, we create a new version and record this against the sprint item 'Fix Version'. So, in the above example, the first 3 sprint items would have a 'Fix Version' of v02.03.01.
The problem is, it starts to feel a bit messy. We can end up with multiple versions listed (one for each of the times we have produced an interim testing build). These all relate to only 1 actual customer release build. So, in the releases section we may have v02.02.03.01, v02.03.02, v02.03.03, v02.03.04, v02.03.05, v02.03.06, v02.03.07, v02.04.01, as shown below in the screenshot.
Do any of you produce a version for each interim build and record it in Jira? Do you archive off the interim testing versions? Do you use the merge versions option?
If I carry on as I have described, when running a query to find all the sprint items in a release, I have to search between v02.03.01 and v02.04.01, rather than just the customer release version of v02.04.01.
I feel as if I am doing this in an inefficient way (or maybe the phrase 'just completely wrong'!).
Any opinions would be welcome.
Thanks,
Jason
You may try to merge interim releases to final customer release. That is you can merge v02.03.01, v02.03.02, v02.03.03 to v02.04.01. At the end, you are actually releasing v02.04.01 version to customer.
You can use betweenVersions JQL of our "Configuration Management Toolkit for JIRA" app. But I think it is a little overkill and using build-in merge function is a lot easier.
Thanks for the reply. I tried the merge versions like you said, and that probably is the easiest solution for my needs.
Thank you,
Jason
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I tried merging but I don't think it's a good idea because by doing that I loose some of the information, such as a fix to something that caused some other bug that wasn't there before and so on. In a addition to that, at the end, when i need to gather all the issues from all the interim builds, i need to make sure I dont miss anything.
I'm missing a build number to a version, like there's a Resolution to a Status.
Any better idea then just merging?
BTW, archiving a version makes it to be unavailable to searches
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
On the above scenario, if I still want to be able to see at the end of the sprint, what was released to QA environment in each interim build and then also have one final release version to see whats released in the sprint.
Do we have any solution to that?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.