Epic -> Feature -> Story, Task -> Sub-task
In this documentation, I will show you how to keep the Epic link and issue link between issues and work items in Jira Cloud and Azure DevOps
Depending on your instance you can use different issueTypes.
1) From Azure DevOps to Jira Cloud
ADO Outgoing Sync
First, we need to add a few new lines in the Outgoing script.
We need the parentId to check if an issue has a parent so we can link them together.
With the httpClient we get the relations of the issues if the issue does not have a relation to another issue we don't set the "replica.relations" variable.
Jira Cloud Incoming Sync
In the Jira Incoming sync, we'll start from the top and work to the bottom, you'll just have to Copy & paste these values and change some values so they match your instance.
It will be clear where and when you need to change these values.
The first code we are going to change is in the if(firstSync) block.
1) First sync block
Change to your values
Change the projct name the your project name & Change the typeMap to your issueTypes (you can choose how you want to map your issueTypes).
- So first you need to change the project name to your Jira Cloud project name.
- Change the values in the typeMap to the issueTypes you have on your ADO instance (the types before ":") and the IssueTypes on your Jira instance (the types after ":")
- Example: ["Azure devOps":"Jira Cloud"]
- On line 11 we'll set the issueType when the type is found in the TypeMap it will set issueType to that value if it's not found it's going to look if the issuetype exsists in your project if not it will set it to a default value, a Task in this case.
- Then on line 14, we check if the issueType is an epic, if it's an epic we will set the Epic name to the given summary
2) Link issues
Here we will determine which issue needs to be linked to which issue, If the issue does not have a parentId it does not need to be linked.
Change to your values
The issueTypes shown below can be different than your issueTypes (Feature) can be something else on your instance.
- We are going to check if the issueType is a Feature (this can be different in other instances, change "Feature" to the issueType that suits you) and that the parentId is not empty
- The Feature here is linked under the Epic so when it's a feature we will link it to the Epic if the parentId is not empty.
- When the next issue (Story) has a parent (Feature) they have a relation link and then the 2 issues will be linked together
3) Status mapping (additional)
If you also want to map your status for multiple issueTypes you can use this function.
Change to your values
Change the values to the values you get from ADO (first values before the ":") and the values you have in your Jira issueTypes (last values after the ":")
4) System & Custom Fields.
Now we have done the parent-child link we only need to add the System or custom fields that you also want to set in your Jira issue.
2) From Jira Cloud to Azure DevOps
Jira Cloud Outgoing Script
First, we need to add a few values in the Jira Outgoing sync.
By default "replica.parentId = issue.parentId" is already in the outgoing script but check this to be sure.
We need the linked issues and the parentId to see in ADO which issues are linked with each other.
Azure DevOps Incoming Sync
Here we also start from the top to the bottom, you can also copy & paste these values and change them where needed to match your instance values.
It will be clear where and when you need to change these values.
1) First sync block
Change to your values
Change the projct name the your project name & Change the typeMap to your issueTypes (you can choose how you want to map your issueTypes).
- So first you need to change the project name to your Jira Cloud project name.
- Change the values in the typeMap to the issueTypes you have on your Jira instance (the types before ":") and the IssueTypes on your ADO instance (the types after ":")
- Example: ["Jira Cloud":"Azure devOps"]
- On line 10 we'll set the issueType when the type is found in the TypeMap it will set issueType to that value if it's not found it's going to look if the issuetype exsists in your project if not it will set it to a default value, a Task in this case.
2) We will set the parentId if the remote issue has a parentId
Change to your values
On line 1 change <ADO Project> to your actual project.
3) Status mapping (additional)
If you also want to map your status for multiple issueTypes you can use this function.
Change to your values
Change the values to the values you get from Jira (first values before the ":") and the values you have in your ADO issueTypes (last values after the ":")
You can add other Issuetype Statues.
4) System & Custom Fields.
Now we have done the parent-child link we only need to add the System or custom fields that you also want to set in your Jira issue.
And you're done This is the implementation to keep the issue link hierarchy.
Here is an image of how a Task and a sub-task are synced over from Jira in ADO.
Here is an image of how the Epic hierarchy is synced over