Deploying JIRA in the Enterprise – Part 3: Everyday administration

This article is the third of a series of three about managing JIRA instances inside the enterprise. This is based on resources from the Atlassian Documentation (here) as well as our knowledge as Atlassian Experts.

In the two previous articles, we particularly focused on JIRA deployment in the enterprise, but the work of JIRA administrators does not stop there. Once your instance is released on production, you need to guarantee the adoption (and correct usage) of the tool by your users. To do that, you need to provide your users with:

A support platform, generally a JIRA project with specific issue types and workflows: support requests, project requests, customization requests, etc. Some of those tasks can be automated to gain some time. For example, project creation can be a specific form. Using our nFeed plugin, you can collect all customization schemes from the JIRA database inside select lists. After the issue creation, an administrator will validate the content and trigger (using a workflow post-function developed in Java) the automatic project creation and the assignation to all customization schemes.

A detailed documentation, generally a Confluence space that contains a FAQ and a description of all processes around your JIRA platform, whether they are technical (How to reboot the JIRA instance?) or functional (How to ask for a new project in JIRA?). The Atlassian documentation is not enough as it is not based upon your customization.

One of the main administration tasks for JIRA Administrators is also to take care of performance. Firstly, it is important to say that the customization you do on JIRA have a direct impact on performance, the more you have the more performance trouble you will get. So, accompany users when they are asking for new customization by trying to reuse existing items (workflows, custom fields). Then, you need to use a monitoring tool that will allow you to follow CPU and memory usage in real time. Unfortunately, this will not be enough to maintain your JIRA instance on the long term. You need to always be ahead of all changes that will happen on your instance. For this purpose, several tools are available:

HTTP Requests log analyzer. This tool will parse your access logs and display a repartition of your requests on your instance. You will therefore be able to detect behaviours that can affect performance (high usage of SOAP/REST requests for example).

JMeter performance tests. Those tests will simulate fictional activity on your platform in order to measure average response times. It is recommended to run those tests on a staging environment before each major modification (upgrade, data migration, etc.)

Slow requests logs (<jira-home>/log/atlassian-jira-slow-queries.log). This file stores all JQL requests that take more than 400 ms to execute on the server. By parsing this file, you can identify users that are running the most time-consuming requests (and as a consequence affect performance).

Performance can indeed be degraded by the behaviour of some users. Another example is the usage of dashboards. By default on JIRA, you can create dashboards that contain up to 20 gadgets even if most of the time it is useless (and all the time memory consuming). We recommend JIRA administrators to reduce that limit to a more reasonable amount (from 6 to 8). Each user can spread his gadgets on several dashboards.

After several years spent on a production server, your JIRA environment often requires an external (and expert!) point of view. You can order an audit from Valiantys that will deeply analyse your instance and will give you concrete improvements to apply on a short, medium and long term.