Uncategorized
The curse of a JIRA Plugin
Atlassian is open and easy to extend
The Atlassian Product suite is very successful thanks to the thriving ecosystem. Thousands of Atlassian users contribute to the product suite on a daily base. Part of the success is the Atlassian marketplace with more than 3500 plugins for JIRA, confluence …
Whenever you have a specific need, chances are high that one of those add-ons will meet that need.
The challenges of an open culture
Extending your Atlassian configuration with new add-ons is very tempting. Basic functionality is enough in most cases, but sometimes they find new use cases such as
- time tracking,
- track release testing,
- gantt charts,
- specialised reports
With great power comes great responsibility
Take into account that adding such functionality has some drawbacks. As add-on developers, we spend a lot of effort to ensure compatibility and stability. Every release requires a huge amount of regression testing.
This blog provides some lessons learned about selecting and using these add-ons.
Selecting add-ons
Following practices can be useful when considering an add-on
- Document, document, document
- Check the vendor
- Follow-up on add-on releases
Document, document, document
Always keep track of the use case of an add-on. Changes are being applied to your environment. You will need to check if the behavior of the add-on is still as expected, after such a change.
So it is very important to document for each add-on at least the following details
- Who are the stakeholders benefitting from the availability of this functionality? Having this list available is always handy to invite for user acceptance sessions.
- What is the business case? Atlassian releases new functionality that can replace an add-on.
- How it is being used to confirm the good functionality of the add-on
- Where is it in use? For instance, if the add-on provides a custom field — what projects are using it, and for what purpose?
- What are the dependencies of the add-on such as links to external databases?
We document all these aspects on confluence and keep track of the configuration in JIRA.
Check the log files
A word of advice — whenever evaluating a new add-on, check out the log files (enable debug logging on the add-on)
Knowing that the development team instrumented the code is always a good sign. Support always needs log files to root cause problems.
Commercial add-ons or not
One of the decisions to make when selecting an add-on is to use a free or a commercial one. In our experience, commercial add-ons are a better choice, as it guarantees.
- compatibility with the latest versions of the Atlassian tools
- proper support in case of bugs, performance problems …
- product fit in the future
It does cost money to develop and maintain an add-on. Check the add-on graveyard to understand why.
Atlassian Verified
Atlassian classifies quality add-on vendors using the ‘Atlassian Verified’ label. These are vendors who meet the following requirements:
- Provide documentation on the add-on
- Provide timely support in case of incidents, problems and/or changes
Check their SLA - Have enough traction (= active installs)
Check the Atlassian Verified program details.
Conclusions
Whenever you deploy an add-on onto your Atlassian environment, ensure that you:
- do proper diligence on the add-on functionality and their vendor
- document the reason and how the add-on is being used
