Connecting two Jira instances

[Deleted user]

We have two Jira server one is our internal and the other is the external. The internal is behind two firewalls and a dmz and we like to synchronize the internal jira to an external jira for a specific project. The connection has to be one directional but the data updates have to be bidirectional. That means tickest can be created on both sides and both should jiras should be in sync, but only one jira is doing the syncing.

Does there exist a plugin, a service or some other means to accomplish this?

[Deleted user · Accepted solution]

We had a change in IT management, and now we were able to "bend" the corporate policys a bit, and we were able to move the JIRA into the DMZ and grant access to the DMZ with a much less restrictive policy and a faster process.

Thanks for all your answers, suggestions and even solutions. We found a way that works for us.

[Piotr_Dorosz]

Hi Michael,

this summer we have released advanced JIRA Synchronizer at

https://marketplace.atlassian.com/plugins/com.intenso.jira.plugins.synchronizer

The idea is that particular issue types in particular project are synchronized with second JIRA project+issue type pair - that's something what we call Contract.
That's the base and next steps depend on needs. You can decide what will be:

• direction of synchronization (JIRA 1 -> JIRA 2, JIRA 2 -> JIRA 1, both)
• what will be synchronized (creates only, creates and updates, any other events configuration)
• what field will be synchronized/mapped
• if there should be a field with reference to second issue
• if synchronize comments
• if synchronize attachments
  and you can configure that separately for each JIRA

[Nils Bier _K15t_]

Hi Michael

Another possibility to sync an internal with an external JIRA instance is to use Backbone Issue Sync for JIRA.

Backbone allows you to set up a synchronization between two (or multiple) JIRA instances, even if those systems are separated with a firewall and can't directly connect with each other.
Instead you can use a file binding (either via e-mail or file exchange), allowing the two instances to stay synced. You can find further information about this in our docs:

• Which configuration model to use
• Introduction to the distributed configuration model

I hope that information helps to give you an overview. If you have more questions regarding Backbone, please feel free to get in touch with our support team.

Cheers,
Nils

[3layer (expert)]

Hello Andy, nice to hear you.

I am very happy that JEMH will have native functionality oriented to replication.

Since we already have exchanged direct emails about this, my colleague Pablo may have talked more about this situation with you.

Once you have a stable version of JEMH with these features (for us, the nFeed fields are the big deal), we will make the upgrade to take advantage of it.

And, taking advantage, the JEMH is a great plugin. Great job, man!

[Andy Brook [Plugin People]]

For the scenarios of DMZ JIRA <-> internal JIRA, I've implemented an extension to JEMH as 'Sync Agent for JIRA', all communication is done with XML via email. This solution makes it perfect for environments where exposing an internal JIRA server, even in a DMZ is just not acceptable.

The goal of the Sync Agent is to propogate issue events via the Sync Agent, to an internal JIRA running JEMH that creates new issues and retains a reference to the external issue key, updates to the internal issue are picked up by another Sync Agent, which sends the update back to the external JIRA, also running JEMH. The external JIRA then rebroadcasts this to the external users involved.

Creation events internally and via another Agent, allow internal users to converse with the remote user via the intervening DMZ instance. Marketplace approval is still pending, I expect this out shortly.

https://thepluginpeople.atlassian.net/wiki/display/JSA/Sync+Agent+for+JIRA

Marketplace approval for Sync Agent is pending.

[francis]

Hi Andy,

We've learned the hard way that synchronization based on email is hard to do, mainly because email is very unreliable. I guess that if both instances use the same mail server, you will be fine, but other setups fail, because emails are not always delivered in the same order as they have been sent.

IMO - solutions based on reliable messaging are to be preferred. Will the sync agent support other transport protocols next to email ?

Francis

[Andy Brook [Plugin People]]

Hi Francis,

I think you have a point in a high-activity issue when many parties may be involved actively, but the case Im hitting is really when a remote user logs a call, onto an external JIRA, perhaps adds a few attachments, adds a comment, waits for a response, so ordering isn't going to be an issue, especially, as you say, such a deployment would likely use the same mailserver for Bi-Directional replication.

The current transport is email, with a JEMH XML payload, one of the selling points is that this doesn't need DMZ holes to the internal JIRA for REST traffic. adding an additional REST endpoint within JEMH to handle this is certainly possible, enter https://thepluginpeople.atlassian.net/browse/JSA-2 :)

[francis]

Voted for the improvement. Looking forward to test it out.

[Radu Dumitriu]

Or, you can script your entire WF; this has remoting capabilities on both REST / SOAP: https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.jjupin It works great for us, we managed to implement several remoting solutions so far, and I'm sure there are others out in the wild with the same problem solved.

Check out this sample: http://confluence.kepler-rominfo.com/display/KB/2013/03/13/JIRA+-+Creating+issues+remotely.

[3layer (expert)]

Hello Michael Nitschke,

We developed this exactly solution in one of our customers, where two JIRA instances are in synch, producing and consuming tasks one of other, incluiding complex fields like, status (with very distinct workflows and issue types), attachments, and exotic fields, like "nFeed" and "VertygoSLA" too.

The exchange of information occurs using emails (two accounts, with support of JEMH plugin) and also webservice calls (REST) from internal JIRA (inside the firewall) to the external instance (accessible from the Internet). Due the requirements, these webservice calls are used to replicate workflow status and VertygoSLA fields. Both instances are using HTTPS.

Each full synchronization cicle occurs between 3 and 5 minutes (two emails for each one).

The effort spent until now is around 200 hours of work, and I hope to spend more 50 or 80 until stabilize everything.

We went into production tests on the last Friday, 12.

The solution works well, but is very sensitive. For example, require a fine configuration in JEMH (both sides), something like 8 Groovy scripts (where 2 are listeners), Apache HTTP Commons and JavaxMail API dependencies, hard coded mappgins between fields/status/data transformation and auxiliary fields (to support nFeed replication).

So, in a "programmer slang", sounds like a gelatine :(

For this reason, next semester (or early next year), we should refactory the entire solution to use our (beta stage) plugin Mizura (http://3layer.org/mizura) to achieve this functionality in a more simple and elegant way, including capabilities like data transformation and automatic recovery in case of failures and, also (crazy) a third instance in customer.

[Deleted user]

Thank you for your answers we will consider both ways to connect the two jiras.

[JamieA]

Also, just FYI, jira 5 has a "remote issue copy" feature when you can copy an issue to another jira. Perhaps you can leverage this somehow (in the fullness of time etc).

[Bob Swift OSS (Bob Swift Atlassian Apps)]

JIRA Command Line Interface can be used to script a syncing process as long as both instances have remote API turned on and are accessable from one machine.