200% Delegated Administration for Jira


Imagine the following scenario: an enterprise of several thousand people using Jira with only one administrator responsible for making changes to project configurations. Seems overwhelming, doesn’t it?

Having only one or even a handful of Jira admins to manage large enterprise instances with countless projects and hundreds of requests, creates inevitable bottlenecks. The question is – can you delegate some of the workloads to power users and effectively deal with the scaling challenges?

In the blog below, we explore the root of the problem and solutions to scaling Jira administration.

Flexibility & Responsibility: The Dilemma of Delegated Jira Administration

Jira is very flexible and powerful platform for issue tracking and business process management. With great flexibility comes great responsibility – a small change or mistake in a workflow can impact your production instance and result in inability to check code or resolve bugs.

While some configuration changes are small and generally safe to deploy on production, others are bigger, more complex and potentially disruptive. Jira doesn’t allow for admins to delegate the promotion of small and safe configuration changes to users, while restricting the access to implementing more dangerous configuration operations. Access to administration privileges is all or nothing – granting someone admin access is handing them the keys to the whole castle.

Ideal solution: 200% Delegated Administration for Jira 

The ideal solution would be to ensure 100% flexibility with a 100% control:

  • 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 like to call the 200% Delegated Administration for Jira and it can be accomplished using Botron’s Configuration Manager

Some of the key capabilities of the solution are:

  • 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

In the following paragraphs, we will walk you through the process of implementing 200% delegated administration in Jira.


4 Easy Steps to Achieving 200% Delegated Administration in Jira


Step 1: Sandbox

Non-admin users will not have any permissions to change the configuration of the production Jira instance, 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.

Within the development environment, project administrators can implement any project changes as requested by end users, a then test those changes to their satisfaction, and possibly create Jira tickets describing project requirements.

* The Development environment should be a replica of the production system (same version, same plugins, etc). Data might not be the same and not all configuration areas need 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 to see in Production. The snapshot is attached to the Jira ticket and deployed on the UAT server*, where end users who originally requested the changes will be able to test them.

The final, tested and 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 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 staging environment is under the control of the Jira administrators – they will use the approved snapshot from step 2 and stage it accordingly. With Configuration Manager for Jira they will deploy the snapshot to the Staging environment* and analyze any invasive or unwanted changes that may be potentially introduced to the Production server. They will also mark the time required for the roll-out to production and whether users need to be kept out of the system.

Once the change and impact analysis are completed, the Jira Administrators can schedule the changes to be introduced to the production instance and plan for 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 deploy the snapshot and roll-out the changes to the production instance with complete confidence in the results. Once this stage is completed, they will mark the ticket as resolved and bask in the glory of a job blissfully well done.

The result

With Configuration Manager for Jira, 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.