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.
The Manage stage in GitLab delights business stakeholders and enables organizations to work more efficiently. Managing a piece of software is more than maintaining infrastructure; tools like GitLab need to be adoptable by companies of all sizes and be easy to operate. Setting up your processes shouldn’t be a struggle, and administrators shouldn’t have to compromise on security or compliance to prevent tools from hindering their velocity.
Manage is composed of 4 distinct groups that support our mission of delighting business stakeholders and enabling organizations to work more efficiently. We plan with 3 timeframes in mind:
All of these sections are intended to be short (no more than a few bullets) and help guide our decisions. They live in parallel with our category direction pages, which go into more detail on specific capabilities and are not constrained to specific timeframes.
Access provides leadership on some of GitLab's most foundational capabilities - access control, authentication/authorization, permissions, and subgroups - that enable users to get into GitLab quickly and start getting work done. If we're doing our job correctly, an instance should be able to get a new user onboarded into GitLab without friction: at the right time, with the right level of permissions, to the right resources - all with a great user experience for the new user and the administrator doing the configuration and maintenance.
Optimize helps organizations more quickly recognize the value of their innovations in two ways:
Counter-productive local optimizations are a natural result of a limited field-of-view. By creating situtional awareness informed by analytics and value-stream thinking, we give every GitLab user the superpower of extraordinary insight and efficiency.
Historically, managing compliance programs has been complex and unfriendly. GitLab, as a complete DevOps platform, is well-positioned to take the friction out of managing compliance for your organization's activities and processes within GitLab. The data you need is already unified within GitLab and not aggregated from disparate data sources, which makes the compliance management process simple and friendly.
The compliance group keeps a group-specific direction page. You can look at our individual category direction pages at:
Import's goal is to make the transition into GitLab seamless. Instances rarely begin completely from scratch; almost every organization has existing repositories, projects, and resources that sit on the outside of any new tool after its been adopted. The more we do to help new instances and users start flying in GitLab, the faster they're able to realize value out of the application - and the longer they'll stay.
To best frame these problems we’ve compiled a set of Jobs To Be Done (JTBD) that represent the jobs our users are hiring us for. If you’re unfamiliar with JTBDs take a look at this article.
When I am responsible for ensuring the compliance of my organization, I want to ensure we meet all required criteria defined in controls and policies, so that it does not create problems for us during an audit.
|When restrictions are necessary, I want to configure an environment, so that I can ensure we are compliant.||Issue|
|When I have complete visibility into adherence of policies, I want to monitor the condition of our software development practices, so that I can address issues before they become more problematic.||Issue|
|When I am preparing for an audit, I want to create shareable deliverables, so that I can provide evidence of compliance.||Issue|
3 years from now, software will be eating the world faster than ever. As Satya Nadella said, "every company is a software company", reinforcing a trend that's had decades to mature. It's a trend that's only accelerating: exogenous events like COVID-19 are putting even greater emphasis on automation and collaboration, even in more traditional industries. Knowledge workers across geographies and industries will thrive, with work becoming more distributed and asynchronous than ever.
While the pie grows, the increasing demand for software increases the spectrum of customer needs in tools like GitLab. New types of customers lead to new requirements - security and compliance, for example - and GitLab will be challenged to continue to expand the needs of these industries and new use cases. DevOps spending is predicted to grow at 23.5% CAGR between 2018 - 2023 (IDC 2019), and a rapidly expanding pie means both catering to these new customers and deepening our relationship with existing personas.
The growth in DevOps spending is predicted to be led by cloud deployment, and for good reason. All things equal, few organizations want to maintain their own tooling infrastructure. A need for control, compliance, and security compels organizations to self-hosted deployments; over the next 3 years, we'll make progress against each of these needs by:
Ultimately, tools that engineers build serve an organization's goal. Whether you're part of a non-profit, a public sector organization, or a for-profit corporation, software is built for a purpose. GitLab's aspiration is to help you measure your progress against that goal better than any other tool. The DevOps toolchain crisis is real, and it doesn't stop at software development - it extends to the many tools companies use to accomplish their goals. While our 3-year goal may not to be displace specific tools well beyond the development workflow, our aspiration is to delight a continually broader swathe of personas in our tool. Delighting business-minded personas are next on the list, by:
According to a 2019 IDC report, only 11% of survey respondents had security and compliance embedded into their DevOps processes. Most see these steps as frustrating, time-consuming bottlenecks that take many people-hours to resolve. Like security, compliance is a team effort - and when shifted left, becomes significantly more painless and cost-effective. We'll build on our compliance roadmap by:
On theme with a wide variety of industries adopting DevOps, our goal is getting customers into the product, getting them started, and getting out of the way. Our challenge is to make GitLab intuitive and easy to use without a steep learning curve; we've built our application on a foundation of small primitives, and our goal is to reduce the amount of configuration and setup you need to get your team productive. We'll get users and organizations to their "ah-ha" moment faster by:
Within 3 years, organizations using GitLab will be able to securely and quickly provide access to the right areas of the application at the right level of access. Administrators will have a hands-free, automated experience that minimizes the time spent operating their instance. Administrators will have visibility into who has system access and mechanisms to enforce their security and compliance requirements.
Within 3 years, organizations using GitLab will be able to provably plan, deliver, and deploy defect-free software faster than any of their peers.
We will automate compliance within GitLab to save time for compliance professionals and remove friction for developers, so they can all focus on the most valuable uses of their time. We will make compliance fast, simple, and friendly and reduce the amount of time spent on compliance activities by at least 50%.
GitLab is currently focused on managing compliance for the activities and processes that exist within GitLab. In the future, we would like to provide similar compliance features and automation for the things you ship from GitLab.
This could include Infrastructure as Code (IAC) templates, deployments, and real-time monitoring of your infrastructure compliance.
Within three years, even the largest organizations will be able to self-service their migration into GitLab from the most common platforms, regardless of their target deployment model.
Through 2021, the Manage stage will provide such compelling, must-have 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 focus on increasing and retaining the number of customers with enterprise-scale needs. We're doing this by focusing on:
|Success factor||How we'll measure|
|Increased self-managed enterprise adoption||At least X customers over Y paid seats purchasing a self-managed license in 2021|
|Increased GitLab.com enterprise adoption||At least 15 customers over 500 paid seats purchasing GitLab.com in 2021|
|Increased engagement with enterprise must-have features||Increase in paid feature engagement for the enterprise: Paid SAML|
|Increased CSAT from large organizations||TBD|
Of particular importance to our goal of enterprise readiness is ensuring that GitLab.com is ready to meet the needs of large organizations. By the end
of 2021, we will close the following gaps between self-managed and GitLab.com:
|Some user events lack auditability and visibility.||Audit events are visible at the group level, including a group-level API. We'll continue to add additional audit events and improve the overall usability of these events over time.|
|Individual members of an organization can fork enterprise projects into their personal namespace, introducing security concerns over IP controls.||Groups can already prevent forks outside their namespace. In the future, [enterprise users will allow organizations to manage project forks, even if they're in personal namespaces.|
|Organizations want to have traceability (and control) over the actions a user's account is taking.||While we don't have plans for an organization to have control over all actions a user's account is taking (a single user account can belong to multiple paid groups; defining account ownership in GitLab.com's current architecture is very challenging), we will allow an enterprise to have visibility and manage user activity that is directly relevant to their organization's group.|
|Since GitLab, Inc. employees are the only admins on GitLab.com, administrative controls for group owners are limited.||We're tentatively planning to pull instance-level admin activity into an administrative area for group owners.|
|Managing credentials (e.g. regular rotation) is not possible, since users belong to the instance and not a particular namespace.||We will allow users to create group specific credentials that can be managed by administrators in a group specific version of Credentials Inventory|
|Since instance-level functionality is admin-only, group owners can't use any features built at this level.||Workspaces and cascading settings will allow us to build features and settings at the group-level so they are accessible in both GitLab deployment models.|
If you'd like to comment on our GitLab.com approach, please consider opening an MR or leaving a comment in this feedback issue.
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:
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:
Access uses a single epic to highlight issues we're prioritizing or refining. If you're not confident an important Access issue is on our roadmap, please feel free to highlight by commenting in the relevant issue and @ mentioning the relevant PM.
In order to reach our vision, we need to:
Towards this vision, the Compliance group at GitLab is focused on three key areas:
Following our vision, the Import group is focused on these goals for 2021:
Simplify settings management for both GitLab deployment models with workspaces and cascading settings.
In pursuit of these goals, Optimize is currently focused on two initiatives:
Enterprise DevOps reporting: understanding instance-level adoption of GitLab is a blind spot for customers of large instances. We'd like to solve for two main problems for executives and leaders: tracking GitLab's ROI and helping find centers of excellence. We'll prioritize work like an instance-level MVC.
Value stream analytics: we will continue building upon the efficiency metrics available through the Value Stream feature, tying them in to DevOps reporting to highlight DevOps best practices that can lead to faster and more reliable software development, while also allowing engineering management to drill in and take action. The value of this work should be immediately apparent to GitLab's Engineering and Quality Departments. We will seek opportunities to dogfood new features, collect feedback from internal teams, and iterate.
workflow::ready for developmentissues by spending 50% of our time on issue refinement each milestone.
To ensure we build a cohesive Compliance experience at GitLab, the following points of view are a baseline for other GitLab product groups to consider.
To support our goals in 2020 and our 3-year strategy, Manage's focus will skew towards paid tiers. Electing to focus on enterprise-level themes like compliance and value stream management is intended to drive company-level financial goals, and we'll prioritize valuable features that customers using GitLab can land and expand into.
We'll also prioritize an approach that doesn't require an enterprise-grade customer to immediately pay for GitLab to realize value. Customers of any size should be able to adopt GitLab and fall in love with it, for free.
Each Manage group should use our Core/Free tier as the primary way to build GMAU and allow our target customer to land in our product. For the most part, features that tend to be "table stakes" for organizations of any size should land in Core/Free - we won't gate GitLab adoption behind a paid tier.
Noting that our pricing strategy directs Core/Free toward the individual developer, we also want to ensure that enterprises can quickly realize value from Manage before expanding further. Examples:
The default paid tier for enterprises, Premium will cater to directors operating a medium to large instance. We'll direct features that solve for typical entry-level enterprise needs: reporting and analytics, operational efficiency, security and compliance, and other needs that are must-haves for medium to large organizations. While this type of organization should be able to get started in GitLab at lower tiers, they won't be able to thrive at scale. Examples:
Directed toward an executive likely buyer, Manage will direct capabilities into Ultimate that serve the organizational needs of the complex enterprise operating a large GitLab instance. The difference between a Premium and Ultimate feature is operational efficiency: a large enterprise instance has everything they need to thrive in Premium, but Ultimate features automate and make that same instance much easier to manage, optimize, and operate. Examples:
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.
Manage's Stage MAU is currently being improved. Please see this issue to track progress.
Individual groups track progress against a number of group-specific performance indicators:
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:
You can track our operational goals here.
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.
Organize your projects and restrict access to controlled resources. This category is at the "complete" level of maturity.
Get new projects hitting the ground running with extensible, reusable templates.
Track important events for review and compliance such as who performed certain actions and the time they happened. This category is at the "viable" level of maturity.
Provide customers with the tools and features necessary to manage their compliance programs. This category is at the "minimal" level of maturity.
GitLab features multiple auth mechanisms including LDAP (including Active Directory), OmniAuth, CAS, SAML, Okta, and Authentiq.
Managing who's using your instance and what they can do with user management tools, permissions, and user profiles.
Get an overview of how well your organization is adopting DevOps and to see the impact on your velocity. This category is at the "minimal" level of maturity.
Import existing work into GitLab from a wide variety of sources.
Gather insights about how your organization is planning and prioritizing across projects and groups.
Support for crowd-sourced internationalization of GitLab.
Visualize, manage and optimize the flow of work through the DevOps lifecycle value stream. This category is at the "viable" level of maturity.
This category is at the "viable" level of maturity.
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
GET /personal_access_tokens- to display last usage info Premium Ultimate