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.
Manage helps enterprise customers setup and adopt GitLab quickly, efficiently and securely.
The Manage Stage is at the core of the GitLab platform. It is a glue that spans across different stages and enables our customers to setup and adopt GitLab by providing best in class Authentication and Authorization, a frictionless Import experience to bring your applications into GitLab, Integrations with your ecosystem and an intuitive and effective Navigation system.
The Manage stage is made up of three groups including:
The existing team members for the Manage Stage can be found in the links below:
Manage will make it easier for Enterprises to drive adoption of GitLab by making intuitive experiences throughout the DevSecOps lifecycle. We will lean into land and expand strategy to create easy paths for adoption. We will focus on the following
GitLab has become mission-critical for many organizations. The Manage team will continue to work on ensuring that any security vulnerability that is found is quickly remediated within its SLO. In addition, we will continue to empower admins & group owners by providing them with a robust toolbox to choose from when balancing security requirements with ease of use for their GitLab instance.
We're going to focus on increasing and retaining the number of customers with enterprise-scale needs. By increasing operational efficiency, we will help our customers deliver faster. We will continue to automate the workflows and make it easier for all the user personas to complete their day-to-day ( starting from opening a Jira issue, collaborating through comments and notifications, pinning the most frequented menu items to making admin tasks less cumbersome and more automated ) tasks in GitLab.
The manage stage spans a number of different steps in the DevSecOps lifecycle. Our functionality touches several user journeys of most personas. We are working to improve the user experiences including standardizing the look & feel of UI components using Pajamas, and new and improved navigation. In the future, we may even invest in streamlining search and help bots.
Manage stage aims to delight business stakeholders and enables organizations to work more efficiently. We aspire to answer valuable questions for users and to automate away the mundane. We will not only provide foundational elements to operate efficiently but will exceed the standard and enable you to work in ways you previously couldn’t.
Through 2023, the Manage stage will provide compelling value to large customers that we will be able to attribute over $100M in ARR to Manage capabilities by end of year. This means that Manage is a must-have part of the feature set that supports that customer, or Manage was a key part of their adoption journey.
We're going to drive an Ultimate story that creates obvious, compelling value. The majority of Ultimate's value proposition lies in application security, but we'll strive to improve the breadth of this tier by driving more value in Ultimate, such as:
Success in this theme looks like:
GitLab has become mission critical for many organizations. We will continue to take Shift-Left approach to application security, resulting into more efficient and reliable solutions. In addition, we will continue to empower admins & group owners by providing them with a robust toolbox to choose from when balancing security requirements with ease of use for their GitLab instance.
Manage will create easy paths to support our land-and-expand strategy. There's a starting point for any organization with an expansive new tool, and Manage will make this transition easy by supporting natural starting points - ideally in Core, for all groups - that get our customers started and hooked on GitLab:
Manage will continue to make it easy & quick to accomplish day to day tasks in GitLab. We will continue to double down on automation, reducing the time to value for customers. We will explore innovative ways to derive value using AI trends such as chatbot, LLM models to make it easier to derive value quicker. For instance, continuous/conversational chat feature which reduces the learning curve and makes day to day tasks 3x faster for persona within the platform is one way we plan to make it easier for users to derive value from GitLab.
Roadmap Items at the top of our list:
We are prioritizing permissions that will have the most customer impact. Feel free to vocalize your permissions requests on this feedback issue.
We are beginning work on the front end - today, custom roles is only available via the API.
We welcome contributors! If there is a permission that you really want, we encourage you to take it into your own hands and contribute it to the framework via our instructions.
In 2023, we want to reach a production-quality, easy to use tool for migrating GitLab resources between instances of GitLab. It should gracefully recover from errors and import over nearly 100% of relevant objects.
Since version 14.3, GitLab has supported migrating GitLab groups by direct transfer, where, rather than manually uploading export files, data is transferred directly from the source instance to the target instance. In GitLab 15.8 we included the ability to migrate projects by direct transfer as a Beta. This beta feature is available to everyone, enabled by default on GitLab.com and with some configuration on self-managed GitLab instances. You can read more about the benefits of the method and how to use it in a blog post or directly check the tool's documentation.
Work on migrating GitLab resources by direct transfer can be tracked in gitlab&2771 and is layed out in more deatils in epics:
If you have any feedback regarding the tool, please comment on this feedback issue.
What about migrating projects using file exports?
Once the migrating projects by direct transfer feature is ready for production use at any scale, migrating groups and projects using file exports will be disabled by a feature flag and only migrating groups and projects by direct transfer will be available in the UI and API.
Because migrating by direct transfer requires network connection between instances or GitLab.com, customers that are using air-gapped networks with no network connectivity between their GitLab instances will need to reenable migrating using file exports. They will be able to use migrating groups and projects by direct transfer after we extend this solution to also support offline instances.
We will not fully remove migrating using file exports until we support all our customers with a new solution.
In 2023 we also continue the work to obtain the feature parity and complete maturity of GitHub importer(documentation).
More details in epics:
In the upcoming 6-9 months, we are focused on two main areas:
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:
As 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 identifies who our DevSecOps application is built for utilizing the following categorization. We list our view of who we will support when in priority order.
Manage uses Stage MAU as a primary measure of success. This represents the unique number of users getting value from the stage; all groups should be able to contribute to improving this number.
Individual groups track progress against a number of group-specific performance indicators All links are to the internal handbook:
|Authorization & Authentication||MAU Using Paid SAML|
|Integrations||GMAU - MAU for Jira and Slack Integrations|
|Foundations||PPI Total Clicks on Navigation|
Manage operates under GitLab's values, but is a stage that seeks to particularly excel in certain areas that support our goals above. We seek to be leaders at GitLab by:
There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.
Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.
GitLab user lifecycle management. Includes provisioning users and their attributes. Does not include user profile, groups, projects, or sharing. This category is at the "viable" level of maturity.
Priority: high • Documentation • Direction
Authentication through all points of GitLab - UI, CLI, API. Does not include authentication within other stages of GitLab (for example, job tokens ). Also includes what the individual/process has access to once they authenticate, determined by their role. This category is at the "complete" level of maturity.
Import existing work into GitLab from a wide variety of sources.
Priority: high • Documentation • Direction
Support for crowd-sourced internationalization of GitLab.
Priority: low • Documentation • Direction
How users easily discover and configure product features.
Improve and maintain the features, style, and build process for the GitLab Documentation website.
Priority: medium • Documentation • Direction
GitLab offers a REST and GraphQL API to give customers options on how to best integrate with GitLab.
Integrations are places where the GitLab product connects to features and services from other products. These integrations seek to offer our customers a seamless experience between these products, and range from lightweight features like Slack notifications for projects, to deep and complex integrations with Atlassian JIRA that connect a wide array of functionality throughout the GitLab product. This category is at the "viable" level of maturity.
Webhooks are a generic way for projects to be integrated with any other service. GitLab's 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's design system called Pajamas. Used internally to power GitLab in order to improve user interface consistency and accessibility.
The Manage stage has several features that enable users to quickly get started with using GitLab. These features are available in Core and are Free. However, as we move into specific use-cases for Enterprise customers that need to manage their GitLab organization at scale, features will be introduced into paid tiers as well and are intended to drive company-level financial goals.
Full list of features by tier under Manage stage are here
There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!
import/exportCloud-Native: use remotely stored
Internalvisibility and scoped to root namespace Premium
Last Updated: 2023-05-15