The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
This direction is constantly evolving, 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 group was established to develop and maintain these integrations with key 3rd party systems and services.
This group 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 focusing on integrations that are of the highest value to our largest customers.
Many enterprise organizations rely on systems like Jira, Jenkins, and ServiceNow, and it is often a hard requirement to have a robust integration with these services. Not having that integration 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 available out of the box.
The Integrations group tracks Maturity on a per-integration basis. Each integration is evaluated based on the following criteria:
You can view a list of all of our current integrations on our Integrations page
|Integration||Maturity Level||Documentation||Issues / Planning Epic|
|Atlassian Jira||Viable||Documentation||Open Issues|
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.
The Integrations Group's primary focus is GitLab-hosted First putting reliability, scalability, and security first. This will be our primary focus until FY22Q4 (November 2021).
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 need to visit Jira to do daily tasks. The goal of our upcoming work is to get the features to a point where a typical developer can stay in GitLab for the majority of their Jira needs. We have released an MVC for a Jira Cloud issues integration for GitLab SaaS customers and will be expanding that to self-managed GitLab instances.
We have paused our work on the Jira importer while the Plan stage undergoes a rearchitecture of Issues into Work Items. Once the first iteration of work items is complete (FY23Q1), we will revisit the Jira importer. Our goals will be to assess the work needed to be compatible with the new work items framework and re-assess gaps for a complete migration use case.
Slack notifications are the most common integration on GitLab projects, giving users the ability to send important activity to the relevant channels in their Workspace. We also have a lightweight Slack application that supports a variety of ChatOps related Slash Commands
ServiceNow is a key component in how many of our largest customers handle Change Management. Through ServiceNow, they maintain an audited chain of custody with code changes, approve/deny changes based on a strict approval workflow, and manage deployment on a scheduled cadence. ServiceNow allows these customers to take these audit logs and centralize them with other data that they're using to monitor and report about their compliance regime.
GitLab offers a REST and GraphQL API to give customers options on how to best integrate with GitLab. Up until now, we have not developed a cohesive strategy that optimizes for parity between them and efficiency in maintaining both implementations.
Webhooks are a generic way for projects to be integrated with any other service. GitLab's APIs allow other services to reach in to our data, Webhooks proactively send data to another service when certain events happen. These are increasingly important for external vendors, as they offer a key way to integrate with GitLab that doesn't require them building inside our codebase.
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" for GitLab, it just means we have no intention of doing it at this time.
There are dozens 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 focus on 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 open core project, anyone in our community is welcome to add the integrations they need.
This group 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 Integrations 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 using the ~"group::integrations" label on your open merge requests.
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.
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.
A large part of the success of these companies comes from their enthusiasm around enabling developers to integrate, extend, and interact with their services in new and novel ways, creating a spirit of collaboration and diversity that simply can't exist any other way.
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 on any relevant issues.