What's the best way to manage permissions between Dev and Prod JIRA environments?

We're trying to figure out governance guidelines for my client in JIRA. They've purchased the tool and a bunch of licenses, but are currently light on support funding. In the future, we might have a dedicated JIRA admin who also manages the governance, but right now we're looking for a solution that assumes less-experienced admin support. The original support model assumed a small support team with Global Admin rights, but they're realizing that the features and customizations that our users want are much greater than they anticipated. However, there's still some resistance to giving Global Admin rights to all our PMs. 

My idea is to implement a three-environment model (DEV, TEST, PROD), where we give Global Admin rights to our PMs in the DEV environment, but only Project Admin rights in TEST and PROD. This way, they'll be able to play around in DEV and create any new Issues/Workflows/etc. they want, and then request that their creation be migrated into TEST and PROD by the JIRA Admins (who will have Global Admin rights in all three environments). We'll be able to have our PMs learn the tool and do most of the actual work in creating what they want in the tool, which takes a lot of work out of the hands of the JIRA Admins. I'm trying to figure out if this three-environment model will work, and if we can split up the permissions this way or if it'll run into trouble. 

This question sounds similar to mine, though it is four years old:

https://answers.atlassian.com/questions/24527

2 answers

Hi Tom,

Recently we published a blog post describing a way to solve this problem that is very similar to your idea and also makes the migration of changes between systems automatic - http://www.botronsoft.com/2016/03/29/how-to-deal-with-the-jira-administrator-bottleneck/

Feedback is welcome smile

Thanks!

1 vote
Joseph Pitt Community Champion May 20, 2016

If you are going to use the same screens, workflows, custom field, etc. between projects (one of JIRA's big advantages) you can expect problems with people stepping on each other and creating duplicate fields. One of the Admin's jobs should be reviewing requests and making sure duplicate fields aren't created and any change in workflows is OK with everyone using it. Moving components between JIRA instances can be difficult. As such I don't recommend the process you're proposing.Instead, if they want to experiment download one of the $10 limited user license copies to their machine for them to play with. If they design something they like it can be documented and rebuilt in the real system.

Moving components: https://answers.atlassian.com/questions/234266

Suggest an answer

Log in or Sign up to answer
Community showcase
Asked Thursday in Jira Ops

I'm John Allspaw, Ask Me Anything about incident analysis and postmortems

I'm John Allspaw, co-founder of   Adaptive Capacity Labs, where we help teams use their incidents to learn and improve. We bring research-driven methods and approaches to drive effective inciden...

477 views 2 5
View question

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you