This is the product vision for the Manage stage of the DevOps lifecycle. If you'd like to discuss this vision directly with the product manager for Manage., feel free to reach out to Jeremy Watson via e-mail, Twitter, or by scheduling a video call.
Note that this stage is also involved in delivering improvements for our mobile development and delivery use case. If you have an interest in mobile development using GitLab, please also take a look there.
For administrators and executives, the process of management is always on. It extends to managing people, money, and risk; when the stakes are high, these stakeholders demand an experience and feature set that makes them feel in control. Setting up your processes shouldn’t be a struggle, and administrators shouldn’t have to compromise on security or compliance to make software work for them.
Not only do we want to fulfill those fundamental needs, we want to give you the freedom to work in new and powerful ways. We aspire to answer questions managers didn't know they had, and to automate away the mundane.
For these users, Manage's role in GitLab is to help organizations prosper with configuration and analytics that enables them to work more efficiently. It’s not enough to give instances the ability to meet their most basic needs; as a single application for the DevOps lifecycle, GitLab can exceed the standard and enable you to work in ways you previously couldn’t.
Manage also maintains and iterates on foundational building blocks of GitLab - like projects and groups - that support the rest of the application. Evolving these areas of the product is an ongoing priority for Manage, in order to ensure that we're removing barriers to finding value and helping users effortlessly find solutions to problems that GitLab helps solve.
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.
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.
GitLab features multiple auth mechanisms including LDAP (including Active Directory), OmniAuth, CAS, SAML, Okta, and Authentiq. This category is at the "viable" level of maturity.
Managing who's using your instance and what they can do with user management tools, permissions, and user profiles. This category is planned, but not yet available.
Administration of a GitLab instance through the application's admin panel. This category is planned, but not yet available.
Organize your projects and restrict access to controlled resources. This category is planned, but not yet available.
This category is planned, but not yet available.
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.
Visualize, manage and optimize the flow of work through the DevOps lifecycle value stream. This category is at the "minimal" level of maturity.
This category is planned, but not yet available.
We’re realizing this vision by delivering more powerful insights, making it easier than ever to do meaningful work in GitLab, and iterating on features that enables large organizations to thrive. We're also taking steps forward in improving traceability and security to ensure that GitLab can meet the needs of the enterprise, even in highly regulated environments. Finally, we're also improving the core experience for our end users and making existing features lovable.
As GitLab continues to grow, we want to continue to iterate and improve on existing features. This is especially true of features that help large organizations thrive in GitLab.
We’re continuing to improve on authentication within GitLab, which is of critical importance for managing users at scale. We’re continuing to build out Group SAML for GitLab.com by automating membership and permissions management. We’re also improving OAuth by allowing you to programmatically manage tokens.
We’re also excited to give instances more control and power over how they manage spending. You’ll be able to clearly understand how your instance’s license is being used, with granular control over seats. Alongside making billing easier to understand than ever, we’re also improving our billing portal to give you the power to self-serve changes to your subscription.
Lastly, GitLab’s single application approach to DevOps puts the entire software development lifecycle in a single place. As a result, users don’t have to stitch together an overly-fragmented toolchain - and we want to go deeper in on that advantage with effortless, custom workflows.
As instances thrive, the amount of information flowing through GitLab grows exponentially. An administrator’s job quickly becomes more reliant on automation and tools to help them stay reactive (I need to respond to an urgent request for information) and proactive (tell me about areas of risk).
We'll find new opportunities to tell you something insightful and new about how you’re shipping software. We're doubling down on the power of analytics to provide insight into how instances can reduce cycle time and ship faster.
“Trust, but verify”: GitLab makes it easy to contribute, but administrators should have comprehensive and consistent views on who is has done what. In short, changes in GitLab should be fully traceable.
After code gets merged, it may involve a host of individuals, commits, and objects - while we make it easy to go from idea to production, tracing that history back should also be a cinch. Since the heart of code change in GitLab is the merge request, we’ll add the ability to see the a deep history - including the issues, people, and commits - that led to the change.
Monitoring and traceability should be built deep into the application and allow GitLab to thrive in any regulated environment.
As we continue to build on the themes above, we don’t seek to create a product that’s merely functionally complete; we want to create a GitLab that offers an unbeatable experience that our users consistently fall in love with.
To accomplish this, we’ll be using feedback from users and data to inform how we can make the experience simpler, more accessible, and easier to understand. We’ll polish parts of GitLab that are frequently experienced - like projects, groups, and user onboarding - and iterate until we get to a frictionless experience that people love and return to.
To help Manage scale, we're dividing the Manage stage into 2 separate groups, each working to achieve our stage-level vision described above:
To clarify priorities for these groups, please see the list of specific initiatives that we're focusing on below.
The following lists are intended to be prioritized from the top-down, descending in importance. The order that we work on things may not perfectly reflect the order seen here, for a variety of reasons, including:
|1||SSO for GitLab.com||Lack of a secure, enterprise-grade SSO for GitLab.com is the biggest barrier to more widespread adoption by large groups. Nearly all mid/large size companies have some type of centralized identity management, and supporting provisioning/deprovisioning of users and SSO enforcement for security are must-haves. These capabilities enable enterprises looking for a hosted solution to look at GitLab.com as their solution; otherwise, they're forced to consider GitHub or Bitbucket. The business opportunity for GitLab is very strong.|
|2||Improved access control for groups||Managing access control at scale is a challenge for most large instances; in GitLab, we manage this with groups, which we need to continue to improve on. Organizations still script around common access control tasks, and we should be able to establish access restrictions at the group level like domain/IP whitelisting. This is especially important for GitLab.com, where users can accidentally be added to private groups.|
|3||Comprehensive audit log||Customers operating in regulated environments and large enterprises want a comprehensive, reliable source of truth to use as a single source of truth. We should be able to offer a comprehensive record of what happened and when to make event investigation possible. Without this, some customers feel vulnerable and frustrated by questions that GitLab's audit events/logs can't answer.|
|4||Smart card authentication||Top ask from public sector prospects and customers (along with FIPS compliance). Strong business opportunity for GitLab. Key differentiator since few or no other similar applications support smart card authentication out of the box.|
|5||Inactive user management||Instances, especially some noteworthy customers have struggled with understanding which users on their instance are actually using GitLab. This should be an easy question to answer.|
|1||New onboarding||Onboarding is a strong opportunity for GitLab. Strong onboarding experiences set users up for success and drive retention/revenue by encouraging users to find a magic moment in the product and "stick" to using it. We should develop a strong onboarding experience that introduces a user to the essentials of GitLab, across stages.|
|2||Cycle analytics improvements||Cycle analytics and ConvDev Index are important analytics tools for understanding cycle time and your instance's DevOps maturity, but both need to be improved. We need to fix Cycle Analytics' stage calculations and be able to use it at the group/instance level, and we should refactor ConvDev Index into a more useful DevOps Score that's actionable and demonstrating clear value.|
|3||Storage limits||We'd like to offer configurable storage limits at the group and project level, as well as paid add-on storage on GitLab.com.|
|4||Smart dashboards||GitLab is a wide application with no well-defined "entry point" that spans across stages. The default page is the project dashboard, which tells a user little about what's been going on since their last visit. To help users be more productive in GitLab and explore features across stages, we should define an entry point to the application that tells a user "what they need to know".|
|5||Redesigned project/group presentation||Projects and groups are both first-class citizens in GitLab. Both are fundamental to using our application, and both should be enjoyable to use. We'll iterate on user feedback and ensure that we're presenting project and group information users want to see the most.|
|6||Importer improvements||GitLab usage frequently starts with an import from somewhere else. Our importers should be resistant to error and recover gracefully from failure. We should also make large-scale imports easier to manage.|
|7||New importers||We should continue extending our importers, supporting applications that are in high-demand from our users like Phabricator and Trello.|
For a more comprehensive view of where we're heading, Manage is primarily responsible for the labels below. Each label links to a vision epic, which details our goals and plan for the specified area of GitLab. As always, we'd love your feedback - feel free to leave comments in the respective epic.
|authentication||How users register with GitLab, log in, and maintain these credentials over time. Also includes the authorization, ldap, saml, and oauth labels.|
|audit events||Tracking events in GitLab for compliance and oversight. Our goal is to have 100% of activity in GitLab be recorded and auditable.|
|permissions||Our user-based permissioning model; how we configure and decide which users are allowed to do what.|
|user management||Managing the number of active users who are using an instance, identifying who they are, and making changes to their status on the instance.|
|user profile||Covers both the personal settings page at |
|admin dashboard||Configuration and presentation in the admin panel ( |
|analytics||Analytics features that span multiple areas of the product: Cycle Analytics, Contribution Analytics, and ConvDev Index (DevOps Score/Maturity). Does not include feature-specific analytics like Issue Analytics.|
|projects||Anything related to projects in GitLab, but not including the repository itself or git-specific functionality.|
|groups||Like directories in a filetree, groups are used to organize many projects and people.|
|importers||Getting data in and out of GitLab. Includes importing (bringing information into GitLab from a GitLab project export or other application) and exporting. Also includes the |
|navigation||Specific features have their own navigation, but this label covers common navigation elements across GitLab like the sidebar and topbar. It also covers some features and flows that are shared across stages, like the Activity page.||\|
|gitlab.com||Functionality specific to the operation and success of GitLab.com.|
|internationalization||Translating GitLab into other languages.|
Our vision for Manage - and GitLab - is only achievable with help from the wider community. Many notable features for Manage have been contributed by the community, including SAML(contributed by CERN).
You can contribute to Manage in many ways.
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!
We follow the same prioritization guidelines as the product team at large. Issues tend to flow from having no milestone, to being added to the backlog, to a directional milestone (e.g. Next 3-4 releases), and are finally assigned a specific milestone.
Our entire public backlog for Manage can be viewed here, and can be filtered by labels or milestones. If you find something you are interested in, you're encouraged to jump into the conversation and participate. At GitLab, everyone can contribute!
You can see further details on the prioritization and development process on the page for the Manage team.