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; } } }

Tracking versions deployment status across environments

Thomas Fastenakel

Hi,

We use Jira in a quite standard way to track bugs, stories and other feature + we group them into versions that we release to our client.

When a version is "released", it means to us we have tested it internally (all issues are Done), created a package and that this package has gone "out' and been deployed to one or more environments at the client (e.g. Staging, UAT, Production).

The problem is that, since the version object is very basic, we have no mean of tracking to which environment this version has been deployed. This is of course important information.

I am very surprised to not see something straightforward to address such a simple requirement within Jira, so I suspect to be missing some key concept.

How do you keep track of such information from within Jira ?

Thank you

Thomas

Accepted answers

Brant Schroeder

@Thomas Fastenakel I think this has more to do with how you manage your releases. If you are releasing all the changes to different environments and not having the release always go to PROD you will need to use something like Components or a Custom Field to track on the issue what release / environment it is associated with. You can then use this to create dashboard reports to properly report on the releases.

It might also help to share your release process.

All comments

Brant Schroeder

It might also help to share your release process.

Thomas Fastenakel

Hi @Brant Schroeder and thank you for having taken the time to answer

Regarding our release process, we usually test in local first (different persons can deploy locally from bitbucket). When we consider a new release as stable, we package it and deploy it at our customer's UAT environment (the way we do this depends on the customer's infrastructure). Once the client gives the green light, we deploy the same package to the client's PROD environment. If the client finds an issue, and we accept it, then we create a new version, test it in Local and the cycle goes on again.

Yes, using a custom field to track the environment each issue has been deployed to was our initial thought. But since all issues belonging to the same version are supposed to be deployed to the same environment, I find it not optimal to track this information on the issue level. I would find it much more convenient to track it on the version level.

But unfortunately I don't think it is possible to attach a custom field or a component to a version, am I right ?

So what would be the best practice ?

Thanks again

Brant Schroeder

@Thomas Fastenakel So if I understand you correctly you are creating a release and then deploying that release to each of your customers environments. If this is the case I would use the release process to create the release and then I would have a deployment sprint that tracks the deployment of the release to the customers environments referencing the release.

Brant Schroeder

@Thomas Fastenakel can you mark this as accepted to help others?

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

version

deployment