How best to use JIRA to manage release authorization

Ian Cornwell

We have a release authorization process which requires independent checking of sources, documentation, testing etc and staging of release from development to clone to live environments. A "release" in JIRA does not support this because it cannot have custom fields or workflows. So my staff have started using issues, of a custom issue type, to represent a software authorization record and use these with a custom workflow to manage the release process.

This doesn't feel right, because we are using an issue to represent aspects of a release. For small releases with only one issue, we are creating the original issue, the release issue and the release, and it feels like there is duplication.

I am curious about how others manage release authorisation with JIRA - please share experiences and ideas.

Ian D

I've used each of the following, and a mix therof, on a range of projects:

1. Like you, have used a specific custom issue type called "Software Release", with whatever custom field you need, and track it through its process. Not so elegant, but firmly achieves the requisite "Authorisation" control.

2. Use the Text Box Gadget (along with other release info gadget) on a shared dashboard to communicate key release info. Not an elegant solution.

3. Use a wiki site, e.g. one wiki page per release. If you use the Atlassian wiki (Confluence) there can be single sign-on between the two and insert gadgets onto the wiki page to display the desired Jira filter results/metric gadgets. This can be more elegant solution, but more effort and cost to setup.