Delegated Project Administration
On this page:
Introduction
Imagine you are part of a several-thousand-people enterprise using Jira. Everything is great, and everybody is happy.
But you only have one Jira Administrator for the company, and the administrator is responsible for making changes to the Jira Project configuration: workflows; custom fields; screens; etc. Having only one or a few administrators serving requests for hundreds of projects and thousands of users can be overwhelming. You are likely now imagining a couple questions about how you might relieve the pressure on your administrator by delegating the workload. Questions like, "...why can't some of the power users make some changes themselves? or ...why scaling Jira administration is a challenge?
In the blog below, we explore the root of the problem and solutions to scaling Jira administration.
Flexibility and Responsibility
Jira is a very flexible and powerful platform for issue tracking and overall business process management. But with great flexibility & power comes great responsibility, e.g. one small change or mistake in a workflow can result in the lost ability to check-in code or resolve bugs.
Some configuration changes are small and safe while others are big and disruptive. With Jira 7.0 there aren't ways for the administrator to delegate certain safe configuration operations while at the same time restricting potentially dangerous configuration operations.
Access to administration functions are all or nothing. So granting someone admin access is the same as handing them the key to the whole castle. ...and that's why it is rarely done.
100% Flexibility and 100% Control
In an ideal world, the following is achievable.
100% Flexibility: Non-admin users have 100% flexibility to personally make configuration changes.
100% Control: Jira administrators have 100% control over what changes are introduced.
This ideal scenario we call 200% Delegated Administration for Jira and it can be accomplished using Appfire's Configuration Manager - the #1 admin add-on for Jira.
Highlights of the solution include the following:
Project Administrators develop changes to the Jira configuration of the projects they own.
Any changes to production Jira servers should be tested by end-users and analyzed for non-direct consequences.
Jira Administrators are the single authority with rights to modify production Jira servers.
4 Easy Steps to Achieving Jira Bliss
Step 1: Sandbox
Non-admin users will not have any permissions to change the configuration of the production Jira, but they will have an environment where they can experiment with new project configurations. This environment is called Development* or Sandbox, and companies can have more than one of these "playgrounds". Here, project administrators can implement any project changes as requested by end-users, and can then test the changes to their satisfaction, and possibly create Jira tickets describing project requirements.
The Development environment should be a close replica of the production system (same version, same plugins, etc). Data might not be the same and not all configuration areas need to be identical with the production Jira. Recommended refresh at least once a month.
Step 2: UAT
Project Administrators* use Configuration Manager for Jira on the Development server to create project snapshots containing all the changes they want ultimately deployed to Production. They attach this snapshot to the Jira ticket and deploy it on the UAT server**, where end-users requesting the changes will test them. The final, tested & approved snapshot is attached to the ticket. The process of making a change on the Development server, creating a snapshot, deploying changes to UAT for testing can be repeated until end users are satisfied with the changes. With small changes, modifications are approved within one iteration. When new functionality is added to the project configuration, for example, it can take a few iterations.
The Project Administrators will need the Jira Administrator and Jira System Administrator global permissions on the Development and UAT servers to create and deploy project snapshots.
** The UAT environment should be a close replica of the production system (same version, same plugins, recent data, etc). All configuration areas should be identical with the production Jira. Recommended refresh at least once a week.
Step 3: Staging
The Jira Administrators take full control in this environment. They will use the final snapshot produced in step 2 and stage it. With CMJ they will deploy the snapshot to a Staging server* and analyze any invasive or unwanted changes that may be potentially introduced to the Production server. They will also mark the time required for deployment and whether users need to be kept out of the system. Once the change and impact analysis is completed, the Jira Administrators can schedule the change for production deployment and plan communication and downtime (usually no downtime is required but it is advised that the target system is not under heavy usage during the deployment process).
The Staging environment should be a recent perfect copy of the Production server. Recommended refresh before each staging of changes.
Step 4: Production
The Jira Administrators use the snapshot along with CMJ to deploy the changes to Production with complete confidence. Once this stage is completed, they will mark the ticket as resolved and bask in the glory of a job blissfully well done.
Licensing
A paid license is needed only for the Production Jira instance. You can license the rest of the instances with free developer licenses (both Jira and Configuration Manager).
The Result
With CMJ, the Jira Administrator can automate most processes, save a lot of time and manual work, and eliminate the potential for human errors completely. The tool provides very deep change and impact analysis which helps Administrators understand the effect of the requested changes and make the right decisions for the Production servers and the company.