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.

  1. compatibility with the latest versions of the Atlassian tools
  2. proper support in case of bugs, performance problems …
  3. 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

 

Outline

Subscribe to our newsletter to receive Idalko’s insights & events

    Related Articles