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.
Last Reviewed: 2023-01-08
The Dev Section is made up of the Manage, Plan and Create stages of the DevOps lifecycle. The scope for the Dev section is wide and encompasses a number of analyst categories including Value Stream Management (VSM), Project Portfolio Management (PPM), Enterprise Agile Planning Tools (EAP), Source Code Management (SCM), Integrated Development Environments (IDEs) and Design Management. It is difficult to truly estimate Total Available Market (TAMkt) for the Dev Section, as our scope includes so many components from various industries, but market research from the analyst firm IDC indicates the estimated TAM in 2022 was roughly ~$4.1B, growing to ~$7.6B in 2026 (13.14% CAGR). Analysis: Manage, Plan and Create. Nearly half of organizations still have not adopted DevOps methodologies, despite data that indicates far higher revenue growth for organizations that do so. Migrating a code base to a modern, Git-backed source control platform like GitLab can often be the first step in a DevOps transformation. As such, we must provide industry-leading solutions in source code and code review, as this is not only the entry into DevOps for our customers, but typically the entry into the GitLab platform. Once a user has begun utilizing repositories and code review features like Merge Requests, they often shift “left” and “right” to explore and utilize other capabilities in GitLab, such as CI and project management features.
Per our Stage Monthly Active User data (internal access only), we know that Create and Manage have the highest usage amongst GitLab stages. As such, these stages must focus on security fixes, bug fixes, performance improvements, UX improvements, and depth more than other areas of GitLab.
The following are the updates from the Dev Section for December 2022 (as presented in the monthly Product Key Review). A complete list of released features can be found on the Release Feature Overview page and a complete list of upcoming features can be found on the Upcoming Releases page.
The primary themes for the Product department in FY24 are:
The Dev Section will primarily focus on World-class DevSecOps experience which also includes improving our user experieince and better support for our Enterprise users.
The Dev Section has the highest TMAU of all sections. Because of this, the Dev section will be highly focused on creating a lovable experience for several core workflows throughout the product. We'll also be focused on product architecture improvements, like simplifying groups/projects, which will enable efficiency gains of GitLab product teams as well as an easier to understand user experience for new users of GitLab. Here are the jobs to be done the Dev section will focus on to improve adoption through usability:
The Dev section will be focused on providing a more secure development experience.
The Dev section will be creating a better holistic experience that ties the entire SDLC together connecting planning, source code, deployment and more. This will allow a unique view into the Software Delivery process, allowing you to tie OKRs and other business metrics into you feature development. This will also allow you to identify bottle necks as well as allow team to experiment with different processes to find what boosts their productivity and allow them to practice continuous improvement. DORA4 metrics will help create observability into deployments and production stability. Custom analytics reports will allow to tailor different views for different users of the platform.
Within each stage, the listed items below are in order of priority. The top priority for each stage or group is:
We identify the personas the Dev section features are built for. In order to be transparent about personas we support today and personas we aim to support in the future we use the following categorization of personas listed in priority order.
To capitalize on the opportunities listed above, the Dev section has features that make it useful to the following personas today.
As we execute our 3-year strategy, our medium term (1-2 year) goal is to provide a single application that enables collaboration between cloud native development and platform teams.
In three years, the Dev Section market will:
As a result, in three years, GitLab will:
Our direction for the Dev section is to provide the world’s best product creation and management platform. We believe we have a massive opportunity to change how cross-functional, multi-level teams collaborate by providng a solution that breaks down organizational silos and enables maximum value delivery. We want to provide a solution that enables higher-quality products to be quickly iterated upon. We also want to make it effortless for companies to migrate to GitLab. In order to obtain adoption from incumbent tools, GitLab has to provide substantially more value than our competitors, but do so by maintaining simplicity. The following themes listed below represent how we believe we will deliver this value and is our view of what will be important to the market and to GitLab over the next 3 to 5 years. As such, they will be the cornerstone of our 3-year strategy, and all activities in the 1-year plan should advance GitLab in one or more of these areas.
Code review should be a delightful experience for all involved in the process. Over time, we expect the code review process to evolve from where it is today to become a more automated process in the future. Along the way, incremental improvements will occur, where developer platforms like GitLab will focus on performance and usability of the code review tools. Code review should be an efficient process, and the easier GitLab can make code review, the more efficient dev teams become. Research has shown that better code review should reduce the number of bugs and increase the amount of higher-quality features an organization can ship. The code review process will continue to provide a venue for developers to learn and collaborate together.
As examples, GitLab will:
Peter Drucker has stated “If you can’t measure it, you can’t improve it.” Many software development teams have no way of measuring their efficiency, and even if they do, there is not enough feedback, information, or actionable insights to improve the efficiency of their team. Even then, once efficiency is improved, it can be difficult to tell if a team’s performance is good or bad, as there is often no point of comparison. Even the best performing team in an organization could be worse than the competition. Increasing efficiency is paramount to companies increasing their time to value and helping organizations answer “Is my DevOps transformation working?”
We believe efficiency can be improved in two ways. The first way is to reduce cycle times for existing value stream activities. The second is to question and optimize the value stream into higher value-added activities at each step. GitLab’s vision is to help answer both of these questions: “Am I doing things fast enough?” and “Am I doing the right things?” These two questions are intertwined because the faster an organization can ship, the quicker feedback will come in from users, creating a virtuous cycle of shipping things quickly as well as ensuring the things shipped are the right things.
Today, value stream management is largely focused on visualizing the value chain through deployment. GitLab is uniquely positioned to also visualize, track, and measure value chain activities from the strategic initiative level all the way to captured value from an organization's customer. For example, the value created by post launch activities, such as press releases, blog posts, marketing campaigns, and customer engagement should funnel into value stream management; providing the business with insights and data to continuously improve each step of their value chain.
The market for value stream tools has begun to bifurcate into value stream delivery platforms and value stream management platforms. GitLab can solve for both of the use cases of these markets. In order to become a more successful VSMP platform, we'll need to ensure that we provide support for calculating VSM metrics on 3rd party tools, for example, Jira issues.
As examples, GitLab will provide:
DevOps started with the merging of Development and Operations and has since been augmented to include Security, highlighting DevSecOps as the next trend. There are many other personas that are involved in software development, such as product managers, project managers, product designers, finance, marketing, legal, procurement, etc. These personas will continue to expand until nearly every role at knowledge-work companies touches some facet of the DevOps lifecycle. Over time, organizations will realize that teams who work out of the same platform/set of tools are more efficient and deliver faster business and customer value.
Because of this trend, each persona of the DevOps lifecycle should ultimately be treated as a first-class citizen in GitLab.
As examples, GitLab will provide:
Most enterprise customers have custom requirements that need to be implemented inside of GitLab. Examples of these are controls that spans systems such as permissions, approvals, compliance, governance, workflows, and requirements mapping. It is our belief these needs will exist for many years to come, and we will need to incorporate these to truly become a complete DevOps platform that serves enterprise segments. We will strive to do this in ways that are modern and, where possible, adhere to a “convention over configuration” approach.
Additionally, compliance, auditing, and surfacing evidence of security/compliance posture to auditors will become more important as more GDPR-like legislation is enacted and passed into law. GitLab should make it easy to not only surface and deliver evidence for GitLab controls (i.e. who has access to GitLab, who did what on what group, etc.), but also to track and manage compliance requirements for various legislation our customers may be bound to for the applications they create inside of GitLab.
As examples, GitLab will provide:
Product Managers often struggle with answering the question, "Is the product or feature I just launched successful?" There are many sensing mechanisms to help answer this question, including revenue, users, customer feedback, NPS, etc., but no product currently helps product managers exhaustively manage the product development lifecycle from end-to-end. Many products assist with planning, delivery of code, and deployment, but feedback and iteration are equally as important to product managers as shipping the first iteration. Getting the first iteration out is traditionally celebrated, but is only one of many steps to true product development lifecycle management.
Imagine an experience where product managers can log in and view the "health" of their entire portfolio on one dashboard. It is clear which features have the most value to customers (and by extension to the business) as measured by key metrics, assisting PMs with priortization activities. PMs can quickly identify features or products within their portfolio that need more attention and drill into them, identifying the correct next action to take, whether it's iteration on the feature or perhaps sunsetting it. PMs can quickly create an issue for the next iteration, version control features, view security incidents, respond to customer feedback, drill down into analytics, control A/B tests of the feature, and even interact with users of the feature or product directly by creating ad-hoc surveys or questions for users to answer. Additionally, the experience should allow for ROI analysis and tracking of the ROI after capital has been expended.
Within three years, project management tools will begin evolving to provide this experience and help PMs answer tough product questions. These tools will also assist with measuring and predicting value to the organization before a feature is prioritized by the PM. The ideal solution most likely uses data science, natural language processing (NPL), machine learning, and predictive analytics to assist product managers with decisions both before and after a feature is launched.
As examples, by integrating with GitLab's Analytics and Plan capabilities GitLab will provide:
Local dev environments can be tricky to set up and often require hours to troubleshoot to set up development kits. Even when successfully configured, the "works on my machine" problem can arise as there are likely many differences between production and local environments.
We believe remote development will become a more popular development paradigm over the next few years and will manifest itself in this way: devs will code in places they are comfortable, such as local IDEs and will run code in Kubernetes environments that their IDE is connected to. Okteto is an interesting tool that is solving for this right now.
GitLab is uniquely positioned to serve as a remote development environment as we have a tight integration with Kubernetes as well as a VSCode Plugin in addition to an in-app editing experience in our Web IDE.
As examples, GitLab will provide:
Enterprise customers on Gitlab.com want to be able to fully manage the entire lifecycle of users in their groups. This desire is for efficiency, increased security protocols, and to protect their intellectual property. Typically, these customers will have centralized user management for their enterprise through an IdP like Okta or Azure and use GitLab SSO/SCIM.
We will provide group maintainers administrative control over users whose e-mail address matches a domain that they have proved ownership for. Today, any user provisioned through SCIM and/or an IdP are automatically Enterprise Users. The user claim process allows group owners to find any users that use their company e-mail address but have opened their accounts outside of the provisioning process, and exert ownership over them.
Once users are Enterprise Users, we will provide enhanced management to group owners, for example:
Please see the categories page for a more detailed look at Dev's plan by exploring Direction links in areas of interest. This page will highight direction themes for both one year and three year timelines.
Roadmap Items at the top of our list:
Given that OpenID Connect adoption keeps increasing, we plan to add support for groups within the next couple milestones.
Our current focus areas and engineering investment are broken down by category below, percentages represent how much engineering time on average is allocated in each milestone.
Our current focus is on consolidating groups and projects into one generic namespace container. The highest priority at the moment is to migrate basic project functionality to namespaces. This will enable us to make project functionality available at the group level.
Building onto the migration efforts described above, we are looking to provide functionality at the group level that was previously only available at the project level. First iterations of this effort will be to make the archiving and starring functionality available at the group level, which are some of the most requested features from our customers.
Another big pain point that our SaaS users have is the ability to control their users and groups, which exists in the admin panel for self-managed users. In order to overcome this and create feature parity, we will migrate administrative capabilities to the group and project level so that group/project owners can have more control over their members.
To ensure we can make progress in the other categories, we are currently deprioritizing work on the User Profile. We are supporting but not actively working on improvements.
In 2023 we will focus on two areas:
Users should be able to migrate all groups they own with their projects from one instance of GitLab to another at once. Our goal is to provide an easy to use tool that recovers gracefully from errors and imports over nearly 100% of relevant objects.
This work can be tracked in gitlab&2771.
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 destination instance. We have been working to extend this functionality to projects and we are launching the ability to migrate projects by direct transfer as a beta in GitLab 15.8. This beta feature is available to everyone. It is enabled by default on GitLab.com. GitLab self-managed users can access the feature when instance administrator enables:
bulk_import_projects feature flag, for migrating projects in the groups.This is a major improvement from migrating groups and projects using file exports because:
In the upcoming milestones we plan to focus on:
Next, we will be focusing on:
If you have any feedback regarding migrating groups and projects by direct transfer, please comment on this feedback issue.
Users should be able to reliable and scaleable import all relevant GitHub concepts for projects of all sizes. We track the work in this planning epic.
In the upcoming milestones we plan to focus on:
In the next milestone we want to:
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:
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:
Group Import continuously evaluates and updates the Importers' direction and roadmap. As part of that effort, new Importers such as Trello, CircleCI, Subversion and Azure DevOps (TFS) are being discussed. While these discussions may ultimately lead to the implementation of a new feature or a new Importer, none of them are being planned at this time.
Given our focus on migrating GitLab groups and project by direct transfer and completing the GitHub importer, we are not prioritizing any work that is not in scope of these two efforts. This includes all other importers, as well as issues for GitHub Importer which are not related to our focus area.
Group Import is not focused on the ability to regularly back up and restore your GitLab data, for example nightly backups of all your data. For more information on this use-case, please see the Backup and Restore category direction page.
Add a new Value Streams Dashboard for Executive to enable decision-makers to identify trends, patterns, and opportunities for digital transformation improvements.
While we understand that not all users of GitLab utilize all of our stages, we believe that there is already a lot of information which can be used to deliver valuable insights.
We are starting to build dashboards, which can help end users visualize a custom-defined value stream flow at a high level and drill down and filter to a specific line of code or MR. In the first phases, we will focus on the following:
The Create stage has been actively delivering updates to help your development teams collaborate faster and more effectively. Here are some highlights from recent releases:
To meet our big hairy audacious goal, the Create stage will focus on the following over the next 12 months:
The following will not be a focus over the next 12 months:
Performance and availability: We must invest in the performance, stability, and availability of our application. We will do this by focusing on application limits, diff load times, and ensuring availability is top of mind.
Growth driver: Retention
Choosing to invest in the above areas in 2022 means we will choose not to:
Learn more about our vision for the Manage stage.
Learn more about our vision for the Plan stage.
Learn more about our vision for the Create stage.