nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Two Integrated JIRA's

nithesh nithu

Hi,

I have a requirement as below, need to know the possibilities and pre-requisite for the same.

One JIRA (existing already) to create a ticket and when the ticket is approved, a linked ticket to be created in the another JIRA (new instance) and to follow the remaining process as per the work flow developed. Once the ticket in the New instance is set as Resolved/Completed, the Initial ticket created should be set to resolved.

Thanks in advance.

Accepted answers

All comments

Nic Brough -Adaptavist-

The cleanest option would be to duplicate the project on both Jira systems and use one of the synchronisation add-ons to send the data over to each (Look for Backbone or Exalate in the marketplace)

If you want to do it exactly as you describe, you'll need to come up with two workflows with holes in them (they will both need "with other system" type status), and then write code to create and update the issues appropriately.

francis

Nic - thanks for mentioning Exalate

This is a core use case of Exalate - a Jira Issue Sync solution.

Take into account the other cases where the developers don't consider the issue as a bug, request feedback about some items, or have a similar issue. Establishing such workflow orchestration can become very interesting - especially the discussions around them :-)

If you would like to know more - please book a meeting in my online agenda

https://exalate-demo.youcanbook.me

Francis

unknown

Hi @nithesh nithu,

As Nic mentioned, an issue synchronization add-on such as Backbone Issue Sync for Jira would be a simple way to achieve this (to be clear - I work for K15t Software, the developer of that add-on).

Using Backbone, you could create a synchronization between the two Jira instances, so that whenever an issue is created in the first Jira, a corresponding partner issue would be created in the partner Jira. It's possible to control what exact issue data (fields, attachments, workflow states etc.) get synchronized, and in what direction.

With Backbone's visual workflow mapping tool, synchronizing workflows is also really simple.

If you have any further questions, please reach out to us and we'll be happy to help.

Cheers, Tom.

Yash Doshi_376rox

Had a question, asked it in the thread itself.

Yash Doshi_376rox

We are doing an assessment and we are looking at Exalate and Backbone. The customer has his jira instance behind a firewall and he wishes to integrate with a vendor jira.

From a 'choice of data' to sync, performance, security and risk standpoint - any recommendations on which one does better?

francis

(I'm with the team that builds Exalate)

Hi Yash,

Check the answer from Mathias on your question on the other thread here.

It boils down that both add-ons have their own approach to cover these requirements.

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)

Francis

Yash Doshi_376rox

thanks guys.

I supplied the email to get the whitepaper but did not get it. One question around Exalate was how does the data transmission happen? Via Rest API? I understand you have something called sync processors which consist of groovy scripts to set up the incoming and outgoing.

francis

> I supplied the email to get the whitepaper but did not get it

Strange - I will send it directly. Let me know if you didn't receive it.

> One question around Exalate was how does the data transmission happen? Via Rest API

Exalate provides different deployment models, depending on the underlying tracker. For instance, on Jira Server/Data Center - Exalate is deployed as an add-on, while for HP ALM/QC, BMC Remedy, and certain ServiceNow environments, Exalate is deployed on an On Prem service.

The communication between the Exalate and the tracker depends on the tracker, while the communication between the Exalate agents is based on Rest API's

deployment model overview.png

More of it in the whitepaper.

> I understand you have something called sync processors which consist of groovy scripts to set up the incoming and outgoing.

That's correct. Every environment keeps full control on what information is sent to the other side and how incoming information is handled. This autonomy (and distributed archtecture) is key for any cross company integrations, where each party wants to have full control.

The scripting engine allows for maximum flexibility. It has a steeper learning curve than GUI based interfaces, but it ensures a future proof solution.

Looking forward for your feedback

Yash Doshi_376rox

Thank you for the security paper. It is very detailed and thorough. Are there any performance test numbers that you can share? Nothing too detailed, but I would like to give the benchmarks to the customer so that they are aware. They have a Jira instance that has grown organically and hence I want to be risk-averse.

Jfmeza

Hi Francis In my company we need to replicate or clone a project from our jira cloud to the jira cloud of our client from time to time in such a way that they can observe the progress of the project, exalate can do this?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration

integration