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
@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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Thomas Fastenakel can you mark this as accepted to help others?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You can create an issue type, Version Details. Instead of creation the Version in the table, create a new Version Details issue, where you will be providing the same information you would add to a version(Name, start date, release date ...) but where you can have other attributes (custom fields) that you can associate with the release.
When the Version Details issue is created you automatically will create a Release(Version) with the same details.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Petru thanks for this suggestion which makes total sense.
I just find it surprising (and a bit disappointing) that you do not have standard attributes in the "version" object you could use to track this. I guess it is pretty common to work with different environments (e.g. DEV, UAT, PROD) and having an easy way to track which issue has been deployed to which environment should be a common requirement.
Have a nice day.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.