Distribute Add-ons to different projects in a single Instance

[Michael Ries]

So, since you can choose only one topic I just want to add, that this question also applies to confluence instance

We as a company are running Jira and Confluence one instance each on Server architecture.

We are more frenquently running into problems of clients asking for new add-ons for their projects. The problem lies within administration and security. We aren´t small and certain compliance is in place so we can´t act all agile and just let everyone have each add-on and install whatever they want.

Our instances are managed by an admin-team. the support and administration should always lie within our borders, but on the same time don´t go overboard because our team is relatively small, so managing multiple instances wouldn´t be a solution.

All these add-ons on the marketplace are build up very differently. Some are managed globally, some are activatable per project, and some (example tenable plugin) have only one interface (usable for one project only per instance!) and that´s it.

So my question would be:

is it possible to distribute Add-ons in a way that we can make some add-ons available for certain projects only, but not for others? Are we maybe using the wrong architecture. I read Data Center is maybe able to do something like that for us? how does this work? Do we have to go to multiple instances and if so, is there a possibility to manage these instances from a central point. Add-ons to do so wouldn´t be much appreciated.

Thanks for your time and greetings

[C_ Derek Fields]

Unfortunately, there is no way to do what you want to accomplish. Add-ons are global to the environment where they are installed. This is also true of Data Center. Each node in a Data Center cluster will run the same add-ons, since they are enabled through the centralized database, not on a node basis.

Some add-ons allow you to set permissions as to who has access to certain functionality, but that is not really what you want. 

Best practice, in my experience, is to discourage each team from trying out their own add-ons. Your centralized team should have a well-documented change management process that will evaluate the add-ons to determine a) whether are really adding value or just a cool toy for some develoepr; b) whether there is overlap with an existing add-on; c) whether the add-on will cause conflicts with other add-ons; d) potential cost to the organization. The fact that you are small team will discourage the users from requesting add-ons that can't be well-justified.

Ideally, a team that is making the addon request should be expected to install Jira and Confluence in a separate test environment, install the add-on and test it, and then make a compelling argument for why this add-on is valuable not only for their team but for all users of the production instance.

As the managers of a large, distributed Jira/Confluence instance, you should tightly managing global settings (workflows, custom fields, permission schemes) and only allowing project administrators to make changes that are isolated to their projects.

Let me know if you want to chat off-line about this.

[Michael Ries]

Hello Derek,

thanks for your detailed answer. I was also reading about federate infrastructure, though we are managing our products via our own AD(not crowd) and this will not change.

The topic on setting up new and seperate instances is huge atm and diversified Apps in a single Instance/Datacenter would´ve been huge or at least a huge argument for DataCenter aswell in combination with SAML since we don´t use Crowd as mentioned above. So it is kind of a bummer since I´m pretty hooked on the idea of getting DC.

What do you mean exactly by chatting off-line? I´m always up for informative exchange that´ll benefit our company.

greetings Michael

[C_ Derek Fields]

I am the practice manager for an Atlassian partner. If you want to talk about your issue - contact me at derek.fields@rightstar.com