How to handle connect add-on upgrades that require manual customer approval?

Jira Development Jira Cloud
,
1

Hello Everyone,

I have a JIRA Connect addon, and I am in the process of releasing a new version that contains some major changes which require new scopes for the addon, and force us to do some internal data migration.

If I understand the Atlassian connect guidelines correctly, these changes would require manual approval by the JIRA instance administrator. In the meantime, (until everyone has upgraded), we are supposed to support both versions (new and old).

Can you guys give me some guidance on the operational aspects of this?

  1. Do the instances that haven’t upgraded yet cache the old addon descriptor?

  2. How do I identify JIRA instances that use the old version of a connect addon vs a new version?

  3. How do you maintain both versions at the same time? Some fancy internal routing? Different baseUrl in the descriptor for new vs old? (Something else?)

  4. How long are we supposed to maintain the old version and allow customers to continue using it?

  5. How do you guys manage a ‘beta’ release that should only go out to a small set of specific customers instead of everyone?

Any help would be greatly appreciated
Cheers,

  • Anthony
1 Like
2

Hi,
We have a cloud addon so I can share our experience.

1) Do the instances that haven’t upgraded yet cache the old addon descriptor?
Customers are automatically upgraded when any descriptor changes that don’t involve scope are detected. In your case, customers will not be automatically updated to the new descriptor because of the scope change

2) How do I identify JIRA instances that use the old version of a connect addon vs a new version?
You need to do more on the backend to track what descriptor versions a customer has, we have a probable overkill backend system monitoring console for our system where we can expose this information.

3) How do you maintain both versions at the same time? Some fancy internal routing? Different baseUrl in the descriptor for new vs old? (Something else?)
Ideally you’d leave legacy implementations present, so that the scope of their previous functionality described in your addon remained functional. New features would clearly not be available, providing some degraded behaviour would again be optimal. In our case, if the descriptor is not up to date, we are not able to do X, and customer instance may try to do Y (that is something we no longer implement, for example, due to deprecation by Atlassian (eg remote conditions)

4) How long are we supposed to maintain the old version and allow customers to continue using it?
As long as it makes commercial sense to do so. Usually customers don’t upgrade because they don’t know they need to. We are in this situation now, attempted to communicate with long time customers to advise them to upgrade the descriptor as they are missing “exciting new features” etc!

5) How do you guys manage a ‘beta’ release that should only go out to a small set of specific customers instead of everyone?
We have a separate private DEV addon, authorized by tokens. By keeping it private you can enable access to it entirely separately. We dont use this method as you describe fro exposure to customers, but it could be used in that way.

We deploy DEV versions to the DEV stack, the DEV descriptor is exposed over a different HTTPs server, all web-links and such end up with {{(DEV)}} after. The point, is that we can then (in DEV) install BOTH the public addon, AND the DEV addon, but co-located, which enables us to TEST what happens in production and compare against what the current DEV release does at the same time, in situ.

Alternatively, If you have ‘new’ features you could have some flags on your AC_HOST table that could be used to enable them on a per-host basis.

2 Likes