Best Practices for Managing JIRA Application Add-ons

Still need help?

The Atlassian Community is here for you.

Ask the community

This article requires fixes

This article has been Flagged for fixing. Use caution when using it and fix it if you have Publisher rights.

Platform Notice: Server and Data Center Only - This article only applies to Atlassian products on the server and data center platforms.


This article discusses best practices for managing add-ons in JIRA applications. An add-on is an installable component that supplements or enhances the functionality of JIRA in some way. Add-ons can be maintained using the Universal Plugin Manager.

On this page:

Best Practices

Managing Add-ons

Governance is important. If you install an add on, users start using it and get used to the extra functionality.  If you remove it, you may have unhappy users.  For example, you may install an add-on for extended JQL functionality. Then you disable it because system has grown, more people are using it and there’s a performance hit. But users have gotten used to the JQL extensions and now all custom JQL will be invalid. Users aren’t happy. The important point is that before you install an add-on, ensure there’s a business requirement for it, don’t just install any add-on. Do your due diligence before installing.

Understand what add-ons you have installed

Review installed add-ons and document:

  • Business requirement explaining why the add-on is installed
  • Who uses the add-on
  • Who is responsible for decisions regarding the add-on
Why do I need to do this?

This information will help you to make decisions regarding these add-ons. For example, when preparing for JIRA Application upgrades you see that add-ons require updating or are incompatible with the new version of JIRA. Knowing who uses the add-ons and who can make decisions regarding the add-ons will help you to the determine what actions to take.

Use care when evaluating new add-ons

Use care when responding to requests for new add-ons.

  • Confirm that the new add-on has a valid business requirement and does not duplicate functionality that is already present in your instance.
  • Perform evaluations in a test or staging environment.

  • Users are able to discover and request add-ons using the "Find new add-ons" page. If desired, disable user requests for add-ons.
Why do I need to do this?

Users may discover add-ons and request that they be installed. You might find that the user's needs can be met using functionality that is already available in your JIRA instance. Instead of installing a new add-on you can show the user how to use what is already present.

Evaluating add-ons will cause changes to your data. You should avoid changing your production data until after you have decided that the plugin is one you wish to install and keep. Evaluate new add-ons in a staging environment so that you are not modifying your production data.

You may see unwanted behavior during an add-on evaluation. Performing the evaluation in a staging environment will prevent your production users from experiencing unwanted behavior.

Changes to Add-ons

Test add-on changes

Add-on changes should be tested before being applied to your production environment. Changes include:

  • Installing / Uninstalling Add-on
  • Enabling / Disabling Add-on
  • Updating Add-on version
  • Updating Add-on license

tip/resting Created with Sketch.

Your testing needs will be determined by your own business requirements. A very large instance requiring high stability may need more testing compared to a small instance used by a single team.

Why do I need to do this?

Testing add-on changes in a staging or development environment will help you to know what to expect when making the change in production. In some cases you may see little or no effect when making the change. In other cases you may see more significant effects.

Examples of behavior seen during add-on changes include

  • Temporary increases in resource usage
  • Temporary problems using JIRA, especially any components related to the add-on being changed
  • Related or dependent plugins are updated or temporarily disabled

Minor changes, such as updating a license, should be tested to confirm that that the add-on performs as expected after the change. More significant changes, such as installing and updating add-ons, may require more in depth testing including performance comparisons and user acceptance testing.

Make changes during maintenance windows

Add-on changes should be performed during maintenance windows to minimize the impact on users.

Why do I need to do this?

Some add-on changes may not be noticeable to users. Other changes may have a temporary impact and may even prevent users from working while the change is underway.

The results of the change in your staging environment will help you to assess the impact the change will have on production. In some cases you may feel comfortable changing production outside of a maintenance window.

Instances requiring the highest stability are encouraged to always perform changes during scheduled maintenance windows. See related bug: JRASERVER-64908 - Getting issue details... STATUS

Additional Resources

Establishing Staging Server Environments for JIRA

Universal Plugin Manager

Managing add-ons

Last modified on Nov 2, 2018

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.