The relatively recent arrival of Atlassian tools means they are often installed and used in isolation from established mainstream IT. Fair enough. But as the popularity (JIRA, Confluence, etc.) grows from their ease-of-use and flexibility they are soon found delivering business critical services. Victims of their own success, the inevitable happens. For better or for worse, they end up being plumbed in to the mainstream IS. Its at this point we should stand back and consider our approach…
Let’s take a typical case of a JIRA instance that has evolved and grown in line with changing needs. More often than not, its configuration has become complicated, its performances may be falling short of the mark, and to top it all, no one really knows how to best administer it. To reconfigure it – and ensure it will function well in the future – a governance policy is needed, coupled with a good dose of best practices for its implementation. So, here’s a couple examples to ponder:
Precise classification of objects
When we work at clients’ and we want to add or modify configuration elements, we very often discover administration pages full of randomly named systems :
One can hardly guess the role of the 5 systems presented above based on the name of the objects.
Consequently, we need to research who this system is for and what purpose it serves. The easy option is to create a new system that answers our needs and that we are 100% sure about, even if this implies creating a duplicate.
However, too much of this behaviour risks your JIRA instance quickly becoming overloaded, less easy to use, and difficult to maintain.
To correct this, we will have to impose one classification for each element we will use. Thanks to this classification, you will be able to spot at a glance the purpose of a configuration object, its positioning among all levels of objects offered by JIRA, and, to know the impacts of a potential modification.
When you apply the following pattern to screen names:
differentiating screens becomes easier. This seems tedious at the beginning, but you will gain some precious time on the long run.
Our Services are Mean Stack Developmet | Mern Stack Development | Frontend Development| Web Development
Add-ons: a word of caution
The second most common mistake on JIRA instances is the use of random add-ons. Take care in your choice.
The audits we lead at our clients’ more often than not show up a collection mysterious add-ons installed. Few can recall what they are for, and even fewer why they were installed in the first place.
With our Sherlock Holmes hats on, we end-up enquiring on the Marketplace and/or Google to track down the mysterious add-on and to understand what it is supposed to do. More often than note, the outcome is that the add-on is not really used and can bed de-installed or replaced with some configuration with now impact for users.
Abandoning an “unknown” add-on helps lighten the load on the instance, simplifies its configuration and can bring a performance gain. Remember! Some add-ons, especially reporting ones, are very demanding in server resource.
To avoid making this kind of mistake again, we should ask ourselves the following questions while installing an add-on:
- Is this add-on available on Atlassian Marketplace?
- Does this add-on answer my need?
- Will this add-on be used in other contexts?
- Is my need important enough to install a new add-on?
- Is the editor well-known?
- Does the add-on have a relevant documentation?
- Does this add-on have support tool?
- Does this add-on have a good release rhythm?
- Does the editor release a compatible version of the add-on within a month after a major JIRA release?
If all the answers are YES, then go ahead. Install it. If not, you might want to reconsider.
Conclusion
By implementing these two best practices, your JIRA instance management can improve.