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.
| Stage | Manage |
| Maturity | Viable |
| Last reviewed | 2022-05-06 |
GitLab's vision is to be the best single application for every part of the DevOps toolchain. However, we acknowledge that to achieve this, there are many workflows, custom scripts, and nuanced integrations that customers require and GitLab may not be able to prioritize. To make the most impact towards that vision, we've identified a narrower vision for the Manage:Integrations group:
We will drive GitLab to enable intuitive collaboration with tools our customers rely on so they can capture the most value possible from the GitLab product and its many features.
GitLab will have a robust catalog of lovable, feature-complete integrations that serve customers across all key industries and functions that utilize GitLab. Our customers will enjoy learning about and using our APIs and webhooks to design creative solutions and intelligent workflows, and they'll share GitLab as an example of an incredible third-party developer experience. Partners will have diverse but straightforward paths for contributing or coordinating integrations that expand the GitLab ecosystem and the larger developer ecosystem in ways that provide tremendous value to the developer community. And we'll do this all in ways that align with GitLab's culture and values, by promoting transparency, focusing on iteration, and incentivizing collaboration/contribution throughout the community.
The following GitLab objectives driven by our product strategy will guide our prioritization:
To learn more about the most recent changes in our Direction and how we will be approaching the challenge of expanding our ecosystem moving forward, here's an overview:
Given unlimited resources and time, we'd love to prioritize and support all possible integrations, but our strategy will provide the guiding rules and logic for how we want to focus our group's efforts.
Our strategy for the upcoming 2-3 years is based on three pillars:
The Manage:Integrations group is facilitating the discussion around our APIs with a key objective of improving usability, reliability, and performance for customers and partners in our ecosystem. To identify the key areas of focus, we feel this particular topic will require significant cross-functional support. We've established a working group to drive these topics forward, and will update this section based on the exit criteria below:
For our webhooks, we'll increase the robustness of our webhook offering and align with other teams on how best to achieve an event-driven architecture. This includes making it easier to configure and maintain webhooks, as well as troubleshooting issues, easily redelivering events, and coordinating webhooks into usable workflows.
We will be improving the process of contributing and maintaining first-class integrations, with as little overhead as possible, whether you're a GitLab team member building a new integration, a customer, a partner, or a contributor. This may include:
Project>Settings UICustomers will be able to search across our catalog of integrations that contains useful metadata, making it easier for customers to identify which of their tools they can connect to GitLab. This will help users understand how an integration is maintained, how it's supported, learn how to contribute, and learn about the features and capabilities of an integration.
Once enabled, we intend to make it smoother for users to interact with integrations from the navigation, to enable and manage settings, and by ensuring optimal UX for managing integrations across projects whether using GitLab.com or Self-Managed GitLab.
Areas of configuration we'll want to iterate/improve on are:
During Q4 2022 / Q1 2023, Manage:Integrations will work to shift responsibilities as DRIs of most integrations to individual product teams within the domain areas across GitLab. This will empower product teams to own the comprehensive strategy in their domain, and allow us to best scale to support the need so of our customers.
We will instead redirect our focus to building self-service tools, documentation, guides, best practices, and standards that support our product teams, partners, and contributors to scale the growth of our ecosystem. By positioning our team in the role of a platform team, we believe we can accelerate the process of building and maintaining integrations. We'll also work in a collaboration model to support product teams, help them define their strategy, and execute in a way that best solves for customers and for the business. We'll provide guidance and work to scale that support across product teams so we can achieve our goal of expanding the ecosystem.
Over time, Product Managers in other stages will become owners for integrations that are particular to their domain, giving them full visibility and ownership in serving customers in their domain based on their strategy, as has been the case for many integrations to date (such as SAST/DAST Scanners in Security). Many times, individual groups will have more in-depth knowledge of customer pain points and how integrations should work within their product stage.
The Alliance team will support in establishing relationships and facilitating the ecosystem expansion with technology partners as owners of those relationships and work more hands-on with product teams in each of the domain areas. The Alliance Partner Integration Engineering (PIE) team, which is being newly assembled, will serve a solutions engineering role in guiding and supporting community contributors. The PIE team will guide any other potential partners in how to establish integrations. This team can and should scale based on the needs and impact of community contributions.
A few guidelines for prioritizing integrations across GitLab:
As Manage:Integrations establishes core API and webhook functionality, we'll want to collaborate with product teams within CI, AppDev, and Security areas to define generic patterns that enable scalable integration that satisfies our customer demand.
As we work to better define ownership of integrations across GitLab, this table (in draft) will make it clearer for teams who is responsible for maintenance, security, and new feature development. It will also make it clearer for customers who owns each integration and how deeply it's supported or how much it's being prioritized.
| Integration | Category | Owner (Group) | Author (Contributor/Maintainer) |
|---|---|---|---|
| Akismet | Spam Protection | Data Science:Anti-Abuse | GitLab |
| Anchore | Security | Secure:Composition Analysis | Anchore |
| Arkose Protect | Security | Data Science:Anti-Abuse | Arkose Protect |
| Asana | Project Management | Plan:Project Management | GitLab |
| Assembla | Code Intelligence | Create:Source Code | N/A |
| Bamboo CI | CI/CD | Verify:Pipeline Execution | GitLab |
| Bridgecrew | Security | Secure:Static Analysis | GitLab |
| Bugzilla | Project Management | Plan:Project Management | GitLab |
| Buildkite | CI/CD | Verify:Pipeline Execution | N/A |
| Campfire | Chat | Manage:Integrations | N/A |
| Cloudrail (previously Indeni) | Security | Secure:Static Analysis | GitLab |
| Confluence Workspace | Wiki | Create:Editor | GitLab |
| Checkmarx | Security | Secure:Static Analysis | Checkmarx |
| Custom issue tracker | Project Management | Plan:Project Management | GitLab |
| Datadog | Monitoring | Monitor:Respond | DataDog |
| Deepfactor | Security | Secure:Static Analysis | Deepfactor |
| Discord | Chat | Manage:Integrations | GitLab |
| Drone CI | Chat | Verify:Pipeline Execution | GitLab |
| Emails on Push | Manage:Integrations | GitLab | |
| Elasticsearch | Data Warehouse & Search | Data Stores:Global Search | GitLab |
| External Wiki | Wiki | Create:Editor | GitLab |
| Flowdock (CA Technologies) | Chat | Manage:Integrations | GitLab |
| GitHub | SCM | Create:Source Code | GitLab |
| GitPod | IDE | Create:Editor | GitLab |
| Google Chat | Chat | Manage:Integrations | GitLab |
| Gmail Actions Buttons | Manage:Integrations | GitLab | |
| GrammaTech | Security | Secure:Static Analysis | GrammaTech |
| Harbor | Package Management | Package:Package | JiHu |
| IBM Engineering Workflow Management (EWM) | Project Management | Plan:Project Management | Community contribution (open source) |
| Irker | Chat | Manage:Integrations | GitLab |
| Jenkins | CI/CD | Verify:Pipeline Execution | GitLab |
| JetBrains TeamCity CI | CI/CD | Verify:Pipeline Execution | GitLab |
| Jira | Project Management | Plan:Project Management (temporarily supported by Manage:Integrations) | GitLab |
| JScrambler | CI/CD | Verify:Pipeline Execution | GitLab |
| Kroki diagrams | Diagramming | Plan:Project Management | GitLab |
| Mailgun | Plan:Project Management | GitLab | |
| Mattermost notifications | Chat | Manage:Integrations | GitLab |
| Mattermost slash commands | Chat | Manage:Integrations | GitLab |
| Mend (previously Whitesource) | Security | Secure:Static Analysis | Mend |
| Microsoft Teams | Chat | Manage:Integrations | GitLab |
| Mock CI | CI/CD | Verify:Pipeline Execution | GitLab |
| Packagist | CI/CD | Package:Package | GitLab |
| Pipeline status emails | Manage:Integrations | GitLab | |
| Pivotal Tracker | Project Management | Plan:Project Management | GitLab |
| PlantUML | Diagramming | Plan:Project Management | GitLab |
| Prometheus | Monitoring | Monitor:Respond | GitLab |
| Pumble | Chat | Manage:Integrations | Community contribution (open source) |
| Redmine | Project Management | Plan:Project Management | Community contribution (open source) |
| reCAPTCHA | Spam Protection | Data Science:Anti-Abuse | GitLab |
| ServiceNow - DevOps / Change Management | Change Management | Manage:Integrations | ServiceNow |
| Semgrep | Security | Secure:Static Analysis | Semgrep |
| Slack notifications | Chat | Manage:Integrations | GitLab |
| Slack slash commands | Chat | Manage:Integrations | GitLab |
| Slack application | Chat | Manage:Integrations | GitLab |
| Sourcegraph | Code Intelligence | Create:Code Review | GitLab |
| StackHawk | Security | Secure:Static Analysis | StackHawk |
| Tenable | Security | Secure:Static Analysis | Tenable |
| Trello | Project Management | Plan:Project Management | GitLab |
| Unify Circuit | Chat | Manage:Integrations | Community contribution (open source) |
| Venafi | Security | Secure:Static Analysis | Venafi |
| Veracode | Security | Secure:Static Analysis | Veracode |
| Visual Studio Code extension | IDE | Create:Code Review | GitLab |
| Webex Teams | Chat | Manage:Integrations | Community contribution (open source) |
| Youtrack | Project Management | Plan:Project Management | Community contribution (open source) |
Based on our Vision/Strategy, we will follow and track the following key objectives to identify if our Strategy is effective:
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 |
|---|---|---|---|
| Webhooks | Viable | Documentation | Open Issues |
| Atlassian Jira | Viable | Documentation | Open Issues |
| Slack | Viable | Documentation | Open Issues |
| ServiceNow | Minimal | Documentation | Epic |
| Microsoft Teams | Minimal | Documentation | Epic |
Slack is one of our most heavily used integrations, is leveraged by customers large and small, and is our primary chat solution outside of GitLab To-Dos and Notifications, which allows for dogfooding and rapid feedback loops.
Today we have multiple Slack integrations, but our goal is to consolidate and simplify our integrations into a single Slack Application that serves GitLab.com and GitLab Self-Managed customers, making it easier for users to access the full set of features, as well as to improve the efficiency of our development/maintenance.
See our planning epic.
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. Webhooks also give users, customers, and partners a more efficient pattern for receiving data triggered based on events, rather than inefficiently polling to see if any new events are available.
Our top priorities in this category are:
See our planning epic.
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.
Self-managed GitLab users will soon be able to use the GitLab for Jira Cloud app.
Support for Personal Access Tokens will give Jira users an alternative to basic authentication, and a more secure pattern for managing credentials for their integration.
Customers are also increasingly interested in leveraging Jira issue data within GitLab's Value Stream Analytics, which will focus on surfacing issue start/close data into GitLab reporting.
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.
In coordination with ServiceNow as a partner, ServiceNow is actively working to enhance their GitLab Spoke to support more actions for CI/CD, Incident Management, MR Management, and Package Management.
We'll next be exploring an MVC for a native GitLab integration that enables Ultimate users to facilitate Change Management between GitLab and ServiceNow.
GitLab offers a REST and GraphQL API to give customers options on how to best integrate with GitLab. Until now, we have not developed a cohesive strategy that optimizes for parity between them and efficiency in maintaining both implementations.
Immediate next steps, as a function of our API Working Group are:
RaisinAs we continue to scale how we support integrations at GitLab, we'll be working closely with product teams to shift support and prioritization to the relevant areas of the product. Similar to APIs, webhooks, audit events, authentication, and other horizontal services, integrations are better supported by the teams closest to the source of customer pain and need. Rather than centralized prioritization, this enables teams to think outside of the box about how integrations can take their features to the next level, gain more exposure from new audiences, or integrate strategically with competitors to achieve business outcomes.
To support teams in building integrations, we'll be focusing on the technology and tools product teams will leverage to build integrations, including our APIs, webhooks, our Static Integrations DSL, and further abstractions to simplify the process of building integrations.
To achieve this we'll be focusing on the following areas:
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 are focused on the priorities listed above.
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.
When it comes to owning and building native integrations at GitLab, the Manage:Integrations team will be focused on the tools and technology required to scale integrations at GitLab - including APIs, webhooks, and self-service platform tools for building integrations (for GitLab product teams, customers, partners, and contributors).
Throughout FY24, we'll be working with product teams at GitLab to clarify DRIs for each integration.
We'll continue to support core functionality for cross-stage integrations, primarily with Chat integrations, such as Slack, Google Chat, and Microsoft Teams. Cross-functional teams, however, will be responsible for building new domain-specific integration features that apply to their particular product group or stage.
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.
We're inspired by other companies with rich, developer-friendly experiences like Salesforce, Shopify, Twilio, Stripe, and GitHub.
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.
This direction is constantly evolving, and everyone can contribute:
~"group::integrations" on any relevant issues.