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: 2021-07-13
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), Design Management, and even Information Technology Service Management (ITSM). 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 2020 is roughly ~$2B, growing to ~$4.3B in 2024 (18.31% CAGR). Analysis: Manage Plan Create. NOTE: The large disparity in the TAM/SAM (Serviceable Available Market) approaches is due to percentage attribution of DevOps revenue. For example, in the IDC report, it specified a certain percentage of Atlassian revenue for DevOps, but in the bottoms up analysis most of Atlassian revenue would have been counted since we looked at all project/portfolio management revenue.
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 we know that Create and Plan 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 July 2021 (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 FY22 are:
The Dev Section will primarily focus on adoption through usability and SaaS first, but will also contribute to becoming a leader in AST through connecting developer workflows through issues and merge requests to AST.
The Dev Section has the highest TMAU of all sections, over 2.7M TMAU. Because of this, the Dev section will be highly focused on creating a lovable experience for several core worklows 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 highly focused on providing a SaaS first experience for GitLab. For other sections, this may mean deciding to ship features at the group or project level instead of instance, but for us, it's about making fundamental product changes to provide an instance like experience at the group level. We'll do this by shipping a workspace, which is a new instance level object, moving applicable Admin Panel settings and features into the workspace, and ensuring proper cascading of these settings and features. Here are the initiatives the Dev section will focus on to ensure a SaaS first experience:
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, 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:
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.
Primary Personas Served:
1. SaaS First & Enterprise Readiness: GitLab must be seen as a platform that enterprises can use out of the box for both GitLab.com and self-managed deployments. We're doing this by focusing on improvements in several key areas:
Growth driver: Initial purchase
2. Compliance Management: GitLab should make it easy to provide compliance of the applications you develop inside of GitLab as well as ensuring GitLab itself is compliant. We'll be focused on a great experience for both of these use cases.
Growth driver: Initial purchase
3. Providing a great import experience: Few instances start from scratch - for most, one of the earliest tasks for a GitLab administrator is importing information from outside the application. We'll win by creating easy paths to adopt and fall in love with GitLab:
Growth driver: Initial purchase
4. Actionable analytics: We've made great improvements in 2020 by releasing code review analytics, value stream analytics customization and filtering, and adding lead time and cycle time. We want to be able to prove the value of Gitlab by surfacing usage trends and delivering an enterprise devops report area where executives and leaders can view usage and metrics for teams and projects that they care about. We'd like to solve for two main problems for executives and leaders: tracking GitLab's ROI and helping find centers of excellence.
Growth driver: Retention
Primary Personas Served:
1. Support for better Agile Planning: GitLab users are able to assign a single milestone to an issue; however, many Agile methodologies require multiple timeboxes in order to support the process. For example, a story can be assigned to a longer term milestone, while also being part of a one week sprint. In GitLab 13.2 we released our MVC of Iterations in order to allow users the ability to timebox with Milestones and a separate timebox for an Iteration. We'll continue to iterate on this functionality by providing better reporting and insights in the way of burn up and burn down charts, reports, metrics based on time/weight, and progress indicators for each iteration. Additionally, we're currently taking a look at how groups and projects work together and how they can be improved to have a significantly better planning and sharing model inside of GitLab. We'll also be looking at how to enforce workflows and provide custom fields in GitLab for organizations that are looking to migrate to GitLab Plan from legacy tools.
Growth driver: Initial purchase & Expansion
2. Best in class planning boards: GitLab has an opportunity to re-design board-based workflows for product development teams. Our boards need to evolve to be a primary interface, an experience where:
Growth driver: Retention with a transition to initial purchase
3. Enhancing Portfolio and Group Roadmaps: Provide easy-to-use roadmaps at the portfolio, project, and epic level that allow users across the organization to see how work is progressing and identify dependencies and blockers. Organize and prioritize work though dynamic roadmaps in real time. Our current roadmap product works fine for epics, but only provides basic functionality. Roadmaps need to include all the necessary information to assess and react to your development plans (milestones, progress, timeboxes, dependencies, etc.) as well as interactivity to adjust epics and have these changes saved. Helping our customers to identify key blockers and their critical path will help them become more efficient and get more value out of GitLab.
Growth driver: Expansion
4. Strategic Planning with Initatives and Epics: Provide an enhanced portfolio management experience allowing customers to start planning from the top; creating strategic initiatives, projects, and epics while laying them out on a roadmap prior to issues and milestones being created. We'll enable users to manage strategic initiatives, assign work, measure impact, and allocate resources to each initiative to help deliver tangible business results.
Growth driver: Expansion
5. Requirements Management: Many regulated customers desire to use GitLab for requirements mapping, dependencies, and process management in order to move off of legacy tooling. Tying requirements to code, tests, or manually satisfying them and providing the audit trail is especially important and we can make create an amazing experience inside of GitLab for this. In the near future we'll be focusing on importing and exporting requirements into and out of GitLab.
Growth driver: Initial purchase
Primary Personas Served:
Growth driver: Initial purchase
Fault tolerant Git storage using Gitaly Cluster reduces the likelihood of outages or performance degradations, so that developers remain productive and deployments can always occur.
In FY22 we will build on the foundations laid in FY21 with Gitaly Cluster, to improve the ease of management and performance of Gitaly Cluster. We will achieve this goal by deploying Gitaly Cluster to all of GitLab.com to improve its performance and availability, and harden Gitaly Cluster under extreme production loads. This is not without challenges, particularly managing storage costs at petabyte scale.
It is also important that Gitaly Cluster is deployed to GitLab.com in full, so that the performance and fault tolerance benefits it offers are not exclusively benefits of a self-managed GitLab instance.
Growth driver: Expansion
Binary files are common in many software development projects, from video games to machine learning. It is common to side-load these files through pointer-based approach like Git LFS, but this kind of solution creates significant complexity for everyone who contributes to the project. Git's Partial Clone feature provides many of the fundamental features needed to be a compelling alternative to Git LFS and a pathway to Git from Perforce for binary workflows.
In FY22, we will make these workflows viable for video games and machine learning applications.
Further improvements are still needed for:
Key improvements planned include:
Growth driver: Retention
Code review is an essential best practice of every successful software project. It is necessary for maintaining the quality of code and products. GitLab's powerful and comprehensive code review capabilities make this possible, but have a steep learning curve, and can feel cumbersome and complex.
In FY22, we must make the core code review workflows fast (performance) and delightful (usability) for:
In order to be successful, we will also need to work with Ops and Sec so that testing, quality and security are native to code review. It is important that our solutions do not simply reflect GitLab's organizational structure, but instead solves problems for the people who use GitLab. Success will help developers be more productive, and improve cross-stage adoption.
Key improvements planned include:
Growth driver: Retention
Open source projects not only allow us to use powerful and sophisticated tools, it also provides the opportunity to find and connect with different communities, take on new challenges, and most importantly, provide valuable contributions back to the community.
Many of the same obstacles faced across large OSS projects are also found in large organizations, where collaboration across teams is beset with workflow, security, and access problems.
We want to make GitLab the reference tool to contribute to open source projects and at the same time enable large organizations to set standards and best practices with minimal effort. Complex workflows that enable this collaborations should work out of the box with sane defaults in project setup/configuration.
In FY22 we will build on the solid foundations which allow users to contribute to projects today, namely by improving our forking workflows and by making contributing across GitLab instances fast and easy.
Key improvements planned include:
Growth Driver: Expansion
In 2021, our focus for our editors will be on laying the foundation for long term success and unifying the editing experience around two primary editor components — the Source Editor for code editing experiences and the Content Editor for visual editing of Markdown content. This consolidation and standardization enables us to maintain the editors more efficiently and extend the functionality across multiple categories, such as the static site editor, should also propagate into other editing experiences, such as the issue/MR description and wikis.
Key improvements planned include:
Growth Driver: Initial Purchase
While GitLab is a complete DevOps platform delivered as a single application, we realize that many other tools are used to aid in the product development process and that in certain situations, these tools cannot be replaced. In early 2020, the Ecosystem team moved into the Dev section and is focused on "mass integration" at the Instance and Group level in addition to better integration with popular tools on the market such as Jira, Confluence, Slack, ServiceNow, and Datadog.
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 2020 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.
or in issue/mr/epic list views and boardsor in issue/mr/epic list views and boards