Best way to do configuration management in Jira?

Question

We have several product lines and a weekly maintenance window when we release into production, and an ad hoc window when we release into Test or other environments. Right now, we manage the approvals etc. on this in our defect tracking system (HP QualityCenter) as a separate project where the defects are actual change request tickets. Depending on the environment and product and change type, different levels of approval are required. Whether or not the change was actually deployed into Production (and by who) is also tracked on these tickets.

I want to move this over to JIRA because we are moving to JIRA for requirement and issue tracking.  What is the best way to do this? Should I set up a separate JIRA project? Is this something Bamboo does? (I have no experience with bamboo). Other thoughts?

Thank you for any insight or advice!

Andrew Wolpers · Answer

Amy, no problem!
1. Yes, you could. This is presuming the user attempting to link would have "Browse" permissions for the issue they're attempting to link.
2. This would be another permissioning configuration. Presuming they have basic permissions to perform all functions necessary to work/deploy, then they should be able to. My bottleneck transitions I mentioned above are conditions which are out of the normal, so this shouldn't effect any other permissions.
3. One way to do that could be a few different fields (XXX Approval? Yes/No, for example). If you trusted your users to use these fields responsibly, then you could put them on the edit screen. Otherwise you could create a transition on all/any screens you wanted to just allow a screen to pop up for the approvers. This could be done similarly to the "Accepted" transition above, but restrict access to a particular role or group.
So, say you wanted them to be able to approve something (or sign-off on something) from any step. You could have a transition button, or transition called "Code Approval" for example. This transition would only be viewable to people in a particular role, group or users that have been specifically identified in the conditions on the transition. You would then create a new screen for this that would include your approval field. This transition would not move it forward, so the "From" and "Destination" would be set to the same step. I wish I had a whiteboard to explain this with ;)
5. That's slightly a different zone, but you could definitely integrate Bamboo for a similar process. With Bamboo you could handle the approvals there and further integrate it with workflow steps, but that's a bit larger of a conversation. Long story short, Bamboo is where you would probably want to handle approvals and JIRA is where you would want to have them collected and these defects rooted.

Amy Hogan · Answer

Thanks Andrew-  I have a couple of follow up questions!

* If it was a separate project could I link the CR to issues in another project?
* If the same project, could the CM team be able to easily view and work issues across projects?  The process is after approval, they have to deploy whatever package or changes to production so they need a work queue that is cohesive to some degree.
* I have multiple approvals but they dont have to appear in sequence, how do I do that in a workflow?
* Does Bamboo have any application to this or am I going into a different zone?

Thanks so much-

Andrew Wolpers · Answer

You could do a workflow with an approval process included in it. Essentially, this would be done by having certain transitions/statuses that are blocked for users that are not in either a certain group or role (this would be done in Conditions, on the transition itself).

So, for example your workflow might look something like this:

New -> In Review - > Accepted* -> In Progress -> Committed -> Resolved -> Closed

-> Rejected* (this would lead to close or in review, depending on circumstance)

Note the Accepted. This would need to have the sufficient rights during the transition between In Review and Accepted. Rejected would then be a similar situation, because this is the intended bottleneck for approval and control.

In regards to your project question, it would really depend on your environment. Generally I have seen a lot of change boards go one of these ways:

Separate Project: This would be for an over-arching approval scheme that everything would come through

An Issuetype: This makes it easier to embed within an actual project for product or customer. Something like "Feature" or "Defects" would use a similar verification workflow, in so many words.

Hope that helps 
. Let me know if you need any clarification.