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.
GitLab's vision is to be the best single application for every part of the DevOps toolchain.
As we expand on how our team can make the most significant impact towards that vision, we've identified a narrower vision for the Ecosystem:Integrations Group:
We want 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 incredible Third-party developer experience. Partners will have diverse but straightforward paths for contributing or coordinating integrations that expand our 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.
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 team's efforts.
Our Strategy for the upcoming 2-3 years is based on three pillars:
Strategic Enterprise Partnerships
These 3 categories organize the workstreams that we believe will help us to best execute on our Vision for the GitLab Ecosystem, leveraging the resources and competencies we have at our disposal.
The following statements further highlight how we'll execute in these areas.
To achieve our Vision, we feel it's important to focus first on solving the pain of our Key Enterprise customers.
We will identify the top 20
Strategic Enterprise Partnerships to focus on for the next 2-3 years between the Ecosystem:Integrations team & Alliance team and identify cross-functional teams that will help us achieve a Solution Complete Enterprise Toolchain, pairing with the top ISVs.
Strategic Enterprise Partnerships, we want to design a robust and opinionated Ecosystem comprised of the most heavily used complementary and competitive Enterprise tools our customers leverage. This Ecosystem should provide customers with a complete solution that covers each GitLab Stage, while driving adoption and usage across more stages. Our strategy here will be to choose one or two top partners in each Product Stage or Industry Category and prioritize based on our resourcing and GitLab's greatest gaps/needs (e.g. Slack for Chat/Communications, Jira for Project Management, DataDog for Monitoring/Observability, ServiceNow for Customer Service, and CircleCI as a CI alternative). We'd like to have a "complete" Ecosystem that gives our customers first-class Integration options in each category before expanding to add other tools.
Key Categories include:
We're actively building/iterating on our Top 20 Strategic Enterprise Partnerships [Internal].
To achieve this, we plan on leveraging our GitLab expertise and resources as follows:
Ecosystem:Integrations will begin to gradually shift our focus from building/maintaining Strategic Integrations 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.
Moving forward, Ecosystem:Integrations will not be adding support for new integrations that pertain to other product domains/groups. In the short-term, we will continue to support those where we currently own and will continue to prioritize and support integrations that are core to our business, including Jira, Slack (and other Chat tools), and ServiceNow.
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, and work more hands-on with Product teams in each of the domain areas. The Ecosystem:Integrations team will establish tools and processes to help Product teams in building integrations, such as:
The Ecosystems Integrations team's focus will be to establish processes and build tools for teams to efficiently build and maintain their own integrations, rather than building and maintaining all GitLab integrations.
The Alliance Partner Integration Engineering team (PIE) - 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.
When it comes to the design of our opinionated Ecosystem, we want to prioritize relationships that pair well with Google Cloud and AWS over Microsoft Azure, so we may focus first on building a robust ecosystem that supports businesses that are not as tightly integrated into Azure. This should give us a differentiator by building deeper/tighter integrations, while Microsoft is likely to focus first on making their Ecosystem more closed and locked-in to their cloud.
We'll have a strong emphasis on partnerships/tools that fill gaps for our product, complement our product, and add value for Enterprise customers. For example, Security & Observability capabilities drive higher value for Enterprise customers.
As we work to expand our strategic partnerships, we'll prioritize achieving a Lovable state for each integration, with a focus on stability, reliability, performance, and usability, before we prioritize new integrations. This will provide a stable foundation for our Ecosystem and allow us to move more quickly on new integrations.
In alignment with GitLab's values, we want to encourage and make it easier for users to contribute. To do so, we want to prioritize workflows, tools, and processes that make it possible for contributors to more easily self-serve.
Strategic Enterprise Partnerships, our other two pillars of the Ecosystem:Integration team will support this strategic objective:
1. Guide, facilitate, and lead implementation of an
API Strategy. This will be executed on first through an API Working Group.
The Ecosystem:Integrations team will drive and facilitate 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:
2. Guide, facilitate, and lead the implementation of a standard, scalable
Integration Experience including Discovery, Configuration Management, and Contribution of New Integrations.
This initiative will focus on building a searchable category 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/supported, learn how to contribute, and learn about the features/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:
Beyond the discovery of integrations, we'll want to improve the process of contributing/maintaining first-class integrations, with as little overhead to GitLab as possible, whether you're a GitLab team member building a new integration, or a wider community contributor.
Alignment with GitLab Objectives
Our Integrations team became a Stage only recently and is working to staff up and resume full working capacity following security allocation. However, even with a full team, there's a limit to the number of integrations we can prioritize and complete in a given period. We can explore the number of customer impacting releases here to see that the Integrations team has primarily focused on two key integrations since 13.0: Jira and Slack, in addition to critical core changes to allow for enabling integrations across a project, group, or instance. At a high level, we might estimate no more than 4 new integrations or major integration updates could be developed within a single fiscal year by the Ecosystem:Integrations team. Keeping in mind as well that our team has other responsibilities for supporting our API Strategy and any technical improvements we plan for the Integration Experience.
To set up a foundation for success, it's critical for our team to have a clear understanding of where we're trying to go, how we want to get there with the people/expertise we have, and how we plan to achieve real business objectives, while providing real customer value.
This is an extension of GitLab's overall Vision/Goals and how the Ecosystem:Integration team can make the most impact, and our strategy should explain why we made the decisions we did to create the most possible focus for our team. We'd like to reassess regularly and if we are not achieving our objectives, we'll want to adjust our strategy.
See below for more background:
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|
|Atlassian Jira||Viable||Documentation||Open Issues|
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.
Our current plans are captured in 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.
While we recently implemented limits on Webhooks per plan, we'll continue improving the scalability of this service, as well as improve usability:
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 App via the self-managed proxy.
Customers are also increasingly interested in leveraging Jira issue data within GitLab's Value Stream Analytics as well as adding support for PATs.
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:
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.
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.
This direction is constantly evolving, and everyone can contribute:
~"group::integrations"on any relevant issues.