My scenario includes two instances of JIRA. Both JIRA instance are installed in a closed loop network.
Because of this restriction, what would be the best way to synchronize a project between these two instances of JIRA?
Have a look at the Backbone Issue plugin or Exalate plugin.
I can't recommend you one - since I'm working for the team behind Backbone Issue Sync, but I can happily share some information with you about these scenarios:
If you want to get a demo, drop us a mail at email@example.com.
(I'm with the team that builds Exalate)
Thanks for the presentation and the links - much appreciated.
As answered in the other thread, but added here for other people convenience,
We do have an extensive overview of the design of Exalate in the Security and Architecture whitepaper.
It provides an answer on most frequent asked questions around this subject. You can also book a conf. call to discuss your particular requirements (here)
For Backbone, as I have gone through your material, you prefer to have a centralized configuration rather than a distributed configuration because it makes the configuration easy or something similar. Is there any specific reason around this? I understand the distributed configuration will allow data sync via emails/files and the centralized one does data sync over REST API. Anything else?
Also I would be keen on knowing the performance numbers where both Jira A & Jira B have more than 50k tickets (A lot of them are open) on them. Does backbone have any nos to support? Also, I am assuming the ticket creation rate may play a part in performance i.e if there are 100 tickets created daily vs a 1000 tickets created daily, specially for the distribute use case
@Yash Doshi - you're right that we generally recommend to choose the centralized configuration if possible. The simple answer why we recommend that is we have access to both Jiras in one place and can directly map issue types, fields or workflows to each other.
In the distributed configuration, the main difference is that the data is synchronized via emails/files and the configuration is split into two parts - one at each Jira. On each side, you only configure half of the synchronization which makes it in our eyes a bit harder to administer. The feature set for the synchronization is the same.
Regarding the synchronized tickets, the main load is not on how many tickets are being synchronized in total, but as you point out rather the ticket creation/update rate. I'm afraid I don't have concrete numbers to share, but we've heard of other customers with similar numbers.
I recommend you try it out yourself - or discuss your specific situation further in a demo call. If you're interested, contact us at firstname.lastname@example.org.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event