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!
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.
Thanks Andrew- I have a couple of follow up questions!
Thanks so much-
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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.