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