Category Direction - Integrations

Stage Create
Maturity Viable
Last reviewed 2020-07-28

This direction is a work in progress, and everyone can contribute:


GitLab's vision is to be the best single application for every part of the DevOps toolchain. However, some customers use tools other than our included features, and we respect those decisions. Currently, GitLab offers 30+ Integrations that work with a variety of external systems. Integrations are important to GitLab's success, and the Integrations category was established to develop and maintain these integrations with key 3rd party systems and services.

This category will primarily focus on creating new integrations that support the needs of enterprise customers, as those customers often have hard integration-related requirements that can fully prevent them from adopting GitLab. By supporting these requirements, we unlock new parts of the market which are otherwise wholly inaccessible.


The Integrations direction is to support GitLab's efforts at making our application Enterprise Ready by expanding and creating new high-impact integrations most in-demand by these customers.

Many enterprise organizations rely on systems like Jira, Jenkins, and ServiceNow. It is often a hard requirement to have a robust integration with these services, and not having that integration already can block adoption of GitLab completely.

By making these integrations powerful and useful, we make the lives of our users better—even when they're using other products. This is what we mean when we say that GitLab plays well with others.

Particularly for large organizations, existing tools and services can be extremely difficult to migrate off of, even without any explicit vendor lock-in. Moving thousands of users or hundreds of thousands of existing files or objects off of one system to GitLab can incur more costs than might be obvious at first. Internal tools may be tightly knit with the other internal systems meaning numerous new integrations have to be developed just to keep the business running.

While GitLab has a robust API that supports integrating almost anything you may need, it's a much more powerful experience to have a native integration already inside the application.


The Integrations category tracks Maturity on a per-integration basis. Each integration is evaluated based on the following criteria:

Current High-priority Integrations

You can view a list of all of our current integrations on our Integrations page

Integration Maturity Level ドキュメント Epic/Issue
Atlassian Jira Viable Documentation Epic
Jenkins Viable Documentation Epic
ServiceNow Minimal   Epic
Rally Planned   Issue
Microsoft Teams Minimal   Epic
Jama Under Consideration   Issue


We prioritize our Integrations work based on:

Based on the above scope and these priorities, we're currently only targeting a limited set of products and services–specifically, those listed above and those that are scheduled on our backlog. All prioritized integrations have a target maturity of Complete, and will take precedent over other integrations until they hit that maturity level.

For all other integrations, our team also supports our API so that developers can build anything else they need.

What's next and why

Over the next year, Ecosystem will work on improving our integrations with existing tools and create integrations for a number of new systems. Enterprise systems that we are working on are:

Improving our Jira integration

Jira is one of our most popular integrations, and a common thread we hear is that "developers want to be able to stay in GitLab" and not have to go to Jira to view their work. We're kicking off an MVC experiment to try to pull some minimal Jira functionality in to GitLab to try to address this user concern.

Group and Instance level integration

This is our current top priority. Many of the integrations that we support are key to our customers workflows, which mean that they end up getting enabled on a majority of the projects that that customer has active. Practically, this can mean thousands of individual projects have to be enabled individually. This causes particular pain with even simple actions like rotating an access token or changing a URL endpoint. When integrations are set on a per-project basis, that one token rotation could mean thousands of individual updates that someone has to go do.

Integrating Rally for Project Management

Like Jira, there are many large enterprises using Rally for their project management needs, and being able to connect where projects are being planned directly to the code that is being written is core to the value that GitLab provides.

What we're not doing

Building a "marketplace"

GitLab does not utilize a plugin model for integrations with other common tools and services, or provide a marketplace for them. As an open core project, integrations can live directly inside the product. Learn more about our reasons for this in our Product Handbook.

This does not mean we will never build a "marketplace" inside of GitLab, it just means we have no intention of doing that at this time.

Integrating "everything"

There are hundreds of products and services that customers have requested that we build an integration with, and we sincerely wish we had the time and funding to be able to build all of them. However, since we are a team of limited size and there are only so many hours in a day, we are currently focused on creating the integrations requested by our biggest customers and userbases.

However, we're happy to partner with your company if you'd like to contribute an integration with your product. As an As an open core project, anyone in our community is welcome to add the integrations they need.


This category develops and maintains specific integrations inside the GitLab codebase, but that doesn't preclude you and your team from adding your own. At GitLab, one of our values is that everyone can contribute. If you're looking to contribute your own integration, or otherwise get involved with features in the Ecosystem area, you can find open issues here.

Feel free to reach out to the team directly if you need guidance or want feedback on your work by pinging @deuley or @gitlab-ecosystem-team on your open MR.

You can read more about our general contribution guidelines here.


If your company is interested in partnering with GitLab, check out the Partner with GitLab page for more info.

Integration design guidelines

Special considerations apply to integrations that don't apply to building native functionality. The product handbook has a set of recommendations and guidelines to consider when working on these types of projects.

Feedback & Requests

If there's an integration that you'd like to see GitLab offer, or if you have feedback about an existing integration: please submit an issue with the label ~Category:Integrations, or contact @deuley, Sr. Product Manager, Ecosystem, on any open issues.