Botron Software

Blog

How to deal with the Jira Administrator bottleneck

Part II: 200% Delegated Administration for Jira

The problem: You are a several-thousand-people enterprise and you use Jira. Everything is great and everybody is happy. But you only have one Jira Administrator for the entire company responsible for administering changes during workflow and screen development. Imagine his/her to-do-list and all the ensuing consequences from overtime hours and missed deadlines for the entire company.

Infographics2

In an ideal world: Each of the company’s multiple divisions would be ideally using Jira with different requirements. Each division would have Jira Administrator privileges and each will have the possibility of developing their own workflows and screens for their particular issue types and specific needs, working offline until debugged. Most importantly, whatever one division does in Jira will not mess up the others’ setup. Once everything is bulletproof, the company-level Jira Administrator would approve and import all the configurations.

The solution: So, you need to implement a properly-delegated administration process without jeopardizing the health of the production Jira servers? Enter Configuration Manager for Jira (CMJ) – the #1 admin add-on for Jira used by large enterprises to eliminate the Jira Administrator bottleneck. CMJ conveniently caters to the following needs of large organizations:

–        Project Administrators can develop/suggest changes of the Jira configuration of the projects they own;

–        Any changes to the production Jira server should be tested by end users and analyzed for non-direct consequences;

–        The Jira Administrator is the single authority with rights to modify the production Jira server.

Infographics2

4 Easy Steps to Jira bliss

Step 1: Sandbox

As non-admin users won’t have any permissions to change the configuration of the production Jira, 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 will implement any project changes as requested by end users and will test them to their satisfaction, possibly creating 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 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 would 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 and approved snapshot, should be attached to the ticket. This operation – make a change on the Development server, create a snapshot, deploy changes to UAT, test – 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.

* 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 over. They would use the final snapshot produced in step 2 and stage it. With CMJ they would deploy the snapshot to a Staging* server and analyze any invasive or unwanted changes that might be potentially introduced to the Production server. They would 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 developed, tested and staged to Production with complete confidence. Once this stage is completed, they would mark the ticket as resolved and bask in the glory of a job well done.

Infographics2

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.

 

 

[Tweet "Share the knowledge"]