First-class Jira Integration
Over the last few years, GitLab has been working toward creating an integration with Jira. So far, we've done an okay job at our integration, and many thousands of users are leveraging it. However, we need to set a new bar for where we want to take this integration.
Particularly as our target customer grows in organizational size, we are seeing many customers with hard requirements about our integration with Jira. While we do make quite a lot of efforts to make these two products work together, the UX and workflows between them are not as tightly coupled as possible. Every one of those gaps creates a pain point for our users, and when they are constantly engaged with GitLab projects that are integrated with Jira, it can be very painful indeed.
Our goal for our integration with Jira should be to get it to a point where it can act as a drop-in replacement for our own Plan product. If a project, group, or entire instance wants to leverage Jira, we should make it work with our own product as seamlessly as if it was something we had built ourselves.
Because of the extensible, pluggable nature of Jira, this will not be a simple task. Our value of
convention over configuration is not shared by our peers at Atlassian, and navigating those spaces in which Jira is infinitely extensible but GitLab is not will be difficult. However, but getting those interaction points right is exactly how we will create something that will delight our Enterprise users, and help us get to the next level of growth.
Real time, 2-way data sync - If users are going to rely on both of these tools, the data needs to constantly be fresh. Right now, many integration features are on a "push" basis, where the data only gets updated periodically. In a perfect world, all data shared between these two applications needs to be live-updated to ensure accuracy.
Support for "Jira Connect App"-like experience for self-hosted customers - We currently have an app in the Atlassian Marketplace for connecting GitLab.com with Jira Cloud. This app integrates with the Jira Development Panel, and offers the latest-and-greatest integration that Jira offers. However, the GitLab application in the Atlassian Marketplace is only compatible with Jira Cloud customers, and many customers interested in this functionality are self-hosted. This limitation is because the APIs that power this application are only available in Jira Cloud and do not exist in Jira Server. - Related Issues: &1626
Integrate GitLab CI with the Jira Development Panel - The Jira Development Panel now supports the display of build/pipeline data natively. Particularly because of how much our customers value our CI system, it's vital that we're able to surface that data inside Jira. - Related Issues: #14178
Integrate GitLab Releases with Jira Development Panel - Similar to the CI information above, the Jira Development Panel now supports the display of environment information natively in the UI. As more customers rely on our CI systems for the management of their infrastructure and deployment of their code, it's vital that we surface this data here. - Related Issues: #27986
Creation of Jira Issue from an errored GitLab CI log - The GitLab CI system allows a user to create an issue from an errored GI pipeline. This functionality simply does not work when using the Jira integration, as there is much data that is natively accessible by our systems that we currently do not support with our Jira integration. We should extend this functionality to be able to create an issue from this state and attach/include relevant logs and data that allow a developer to resolve the issue. - Related Issues: #18731
Support for tracking Jira Issues in GitLab Value-stream Management feature - In the early development stages of the VSM tool, customers have already expressed interest in being able to pull additional data from Jira tickets. We need to extend this tool (and the data available via our integration) to allow users to track these metrics inclusive of the data in Jira.
Group and Instance-level integration - Customers using this feature will often have hundreds of projects, which means they have to (currently) configure this integration hundreds of times. This makes it near-impossible for larger organizations to really reap the benefits of using this. By extending our integrations to work at the
Instance level, we reduce the complexity of using these integrations by orders of magnitude. - Related Issues: &2137 #2561 (closed) ux-research#393 (closed)
Significantly improved/simplified configuration experience for Project Service settings - Especially because (today) every project's integration with Jira needs to be integrated on a per-project basis, it's particularly painful how complex the integration process is. We should investigate more modern federation techniques to allow users to integrate on a one-click basis. - Related Issues: &1691 (30 issues)
Support for integrating with Jira instances using SAML/oAuth (or other identity providers) - Today, only instances using traditional user/pass or token-based authentication are functional. As the market moves towards more enterprises adopting 3rd-party SSO and authentication providers (and as Atlassian offers support for those), we expect more customers to suffer from being unable to authenticate against these installations. - Related Issues: #34642
GitLab Integration scoping for specific Jira Projects - Currently, our integration attaches itself to the Jira instance and is unable to differentiate between projects. This can be of some concern to organizations that have strict controls around data access between projects, and we should support the administrators ability to wall certain projects off (or simply restrict a single project to a single namespace/key).
Better support for Transition IDs - Currently, the Jira API can intelligently map Transition IDs for us. However, we require users to specify them directly. We should modernize our integration with the newest Jira API standards to leverage this new functionality, but also offer more sophisticated configuration to allow users to define complex transition workflows inside of GitLab. - Related Issues: #14739 #15607
GitLab Merge Request blocking based on Jira Issue state rules - There are various places inside the GitLab product where we have or are currently considering functionality that allows the blocking of Merge Requests based on specific rules. We should extend this functionality to work with Jira, so users and administrators can specify certain conditions (such as the resolution of an issue being "Closed") as prerequisites for a merge. - Related Issues: #25652 #29460 #2073 (closed)