Jira and Github, an Exalate Case Study
In some organizations, product issues are tracked in multiple locations. This often occurs when internal and external teams collaborating on a single code base or a single project. Internal teams will often use a licensed product such as Jira Cloud; whereas, external and distributed teams tend to use free issue management solutions such as GitHub’s issues. These tightly coupled solutions are often extended by products like ZenHub which add additional project management capabilities to the basic system.
Using multiple issue trackers causes confusion for developers and project managers. Issues become duplicated across systems and cause confusion around what issues are the source of truth for the project. As a result, sprint planning and roadmap creation becomes difficult as the issues within them contain inaccurate data.
We have worked with a few organizations within the public sector, one federal and one provincial, that encountered this very problem. Both scenarios were a result of the open source community engaging with product development.
Both organizations support open source projects hosted in GitHub. The internal project teams use Jira Cloud to manage their feature development and bug fixes, while also obtaining support from external users who use GitHub issues to raise tickets. The project team requested that issues raised in GitHub were also shown in Jira so that internal developers could plan their work. Additionally, external developers needed visibility into the product schedule and sprints.
Exalate is the most flexible synchronization tool and the leading Cross-Company Integration solution. Synchronize your Jira instances, ServiceNow, Zendesk, GitHub, Azure DevOps & any other work management systems.
These projects used Exalate to sync issues between the GitHub and Jira projects enabling a close collaboration between teams. Below is a diagram explaining where Exalate sync fits into the two systems.
It was important to easily identify what issues came from which source (Github or Jira). We were able to meet this requirement by using card layout and colors to clearly indicate which issues are synced with GitHub.
The internal Jira project integrated with around 30 different GitHub repositories. This means that not only did the internal team need to know what issues were from GitHub vs Jira, they also needed to know what repository the GitHub issues were raised against.
We chose to use Jira components to distinguish between internal Jira issues and external GitHub issues. The component was applied using Jira Automation.
A custom field indicating the GitHub repository was added to the issue types in Jira and was automatically synced during the Exalate updates.
These two fields were displayed on the board cards so that Jira Developers can quickly and easily see where the Github Issues originated from.
Another small gotcha, is that GitHub issues don’t currently support custom fields. This means that Jira fields like issue type and sprint values had to be synced to GitHub labels.
Because Jira and Github have significant differences in the fields they support, and because we don’t necessarily want to expose all of the Jira activity in Github, we chose to expose certain updates using Automation for Jira. As an example, we were able to add a comment when the issue status changed. That comment was then sync’d between the two issues so that in GitHub you would see the update. It would look something like this:
The clients have been using this system for about 3 months and have been very happy with Exalate and the ability it gives them.
Our tips for a successful Exalate implementation: keep the synchronization as simple as possible and use Jira Automation to bridge any gaps. This is because updating the exalate configuration is harder than updating an automation rule. It also tends to lead to a more robust setup and the integration point is stronger.
Other than choosing a project name, communication about features and bugs is possibly one of the most difficult issues in software development. Exalate gave these public sector organizations the ability to automate the communication of development and status between the internal and the open source communities. This is just one of the many use cases for Exalate and their extremely supportive team; through out these implementations the people at Idalko/Exalate have been very helpful in diagnosing and providing a workaround for a bug within the Github system.
If you or your organization are experiencing difficulties communicating Jira issues between different systems or teams reach out to see what we, and Exalate, can do for you.