Manage versions in multiple environments

[Goncalo Oliveira]

Hello,

I'm trying to understand if we can with JIRA come up with a solution that helps us manage versions in multiple environments. Let me develop a little bit...

Our products always go through two different production environments, a BETA and a FINAL environment. So, issues are often fixed in more than one version. So far, everything's pretty standard. However, to make sure things are correctly patched in all versions, the QA team usually validates the BETA and FINAL packages when they are built. What would really help was if we could somehow classificate the releases as BETA or FINAL (being able to later change the first one to the last). This would allow us to have in JIRA an overview of which version is in which environment and the issues in each.

Another question is on testing. Issues are verified by the QA team when it's fixed (before there's a version) and, as mentioned above, when they're assigned to a version. What I'm thinking is that it would be good to be able to distinguish between verified in one version and in another version. That is, if the issue is solved in version A and B, there should be some property that I could set as "verified in version A" and/or "verified in version B".

I'm still adapting to this and still evaluation, so maybe there are better ways to do this, so, maybe you can help me out on this one?

Thanks.

[David Berclaz]

"it would be good to be able to distinguish between verified in one version and in another version"

> You can use a Jira app like Xray for managing your testing. It will allow you to link tests to your issues, and run them several times on different versions or environments.

"This would allow us to have in JIRA an overview of which version is in which environment and the issues in each."

> You can use a Jira app called Apwide Test Environment Manager for planning your deployments. It can be fully automated using the REST API and Webhooks.

[Timothy]

This is what I can suggest. You need to have two versions for each release (e.g. 1.0-BETA & 1.0-FINAL) or you can capture these values in a custom field and just use the version field for the version number). You should then have a workflow that branches out if there is a failure for BETA. This ca be done using the workflow condition.

That is, if the issue is solved in version A and B, there should be some property that I could set as "verified in version A" and/or "verified in version B".

You can implement this as a workflow tranistion or an edit action to update the issue.

Another thing that you can do is use two Agile boards (e.g. Kanban). Each Kanban board will only pull certain issues (i.e. BETA & FINAL).

[Goncalo Oliveira]

That is somewhat what I ended up achieving in my tests, though, I'm not fully satisfied with the solution.

I really wish that versions could be more flexible. Custom fields on a version and, let's say, a Kanban board for versions instead of issues would be great.

To us, a version that is a release candidate will eventually reach Beta, and that same version can be sent to production if no issues are found.

[Paul French]

I have the same question - has anything changed in the 3 years since this question was submitted?