GitLab has a broad scope and vision, enabling organizations to collaboratively plan, build, secure, and deploy software to drive business outcomes faster. To provide teams with complete transparency, consistency, and traceability, we are constantly iterating on existing and new features. Some stages and features are more mature than others. To convey the state of our feature set and be transparent, we have developed a maturity framework for categories, application types, and stages that considers both adoption and user experience. These maturity ratings reflect the current state of our categories. In general, we plan to continue working on categories to maintain and improve on this maturity. So even if a category is "Complete," it does not mean we will not keep working on it. We are present-day pessimists and long-term optimists and maturities will change, including changes to lower maturity rating, to reflect the bar we set for ourselves, our position in the market and for customers. Contributions from our community are an essential part of achieving this overall vision for GitLab.
Category and Application Type maturity: | |
|
Planned: Not yet implemented in GitLab, but on our roadmap. |
|
Minimal: Available in the product, and works in the recommended setup. Has utility to the user, but does not completely address the job-to-be-done, yet. Not to be used as a primary selling point, as capabilities are minimal. Suitable to replace the need for existing tools for new companies, departments, and teams. |
|
Viable: Significant use at GitLab the company. CM Scorecard at least 3.14 for the job to be done (JTBD) when tested with internal users. No assessment of related jobs to be done. Suitable to replace the need for existing tools for new namespaces, projects, and environments. |
|
Complete: GitLab the company dogfoods it exclusively. At least 100 customers use it. CM Scorecard score at least 3.63 for the identified JTBDs when tested with external users. Suitable to migrate from existing tools. |
|
Lovable: CM score of at least 3.95 for the JTBD (and related JTBDs, if applicable) when tested with external users. |
Stage lifecycle and recognition:
Product Investment methodology. |
GitLab features are grouped into a hierarchy, representing increasingly higher level capabilities. Features make up a broader Category, which then belong to a DevOps Stage. Stages are assigned a yearly lifecycle, and categories a maturity.
Since 2011 GitLab added:
Stage Roadmap:
Since 2011 GitLab added:
Stage Roadmap:
Since 2012 GitLab added:
Upcoming Categories:
Stage Roadmap:
Since 2016 GitLab added:
Upcoming Categories:
Stage Roadmap:
Since 2017 GitLab added:
Stage Roadmap:
Since 2016 GitLab added:
Stage Roadmap:
Since 2017 GitLab added:
Stage Roadmap:
Since 2017 GitLab added:
Stage Roadmap:
Since 2022 GitLab added:
Upcoming Categories:
Stage Roadmap:
The maturity framework makes it easy to visualize where GitLab is making investments, and resulting category maturity improvements. As part of the planning process for each category, the set of features required and expected date to reach the next maturity is maintained. It can also be used to compare historical to planned velocity. A reduction in velocity is one of our concerns.
Below is a chart which illustrates the aggregate current and future progression of all categories.
Plan |
Stage Lifecycle: Users of other tools start to switch (typically year 5) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
Team Planning | |||||
Portfolio Management | |||||
DORA Metrics | |||||
Value Stream Management | |||||
DevOps Reports | |||||
Wiki | |||||
Pages |
Create |
Stage Lifecycle: Best product in the market (typically year 7) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
Source Code Management | |||||
Code Review Workflow | |||||
Web IDE | |||||
GitLab CLI | |||||
Remote Development | |||||
Code Suggestions |
Verify |
Stage Lifecycle: Best product in the market (typically year 7) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
Continuous Integration (CI) | |||||
Secrets Management | |||||
Code Testing and Coverage | |||||
Merge Trains | |||||
Review Apps | |||||
CI/CD Visibility |
Package |
Stage Lifecycle: Majority of users don’t work at GitLab Inc. (typically year 3) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
Package Registry | |||||
Container Registry | |||||
Helm Chart Registry | |||||
Dependency Proxy | |||||
Dependency Firewall |
Secure |
Stage Lifecycle: Majority of users don’t work at GitLab Inc. (typically year 3) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
SAST | |||||
Secret Detection | |||||
Code Quality | |||||
DAST | |||||
API Security | |||||
Fuzz Testing | |||||
Software Composition Analysis | |||||
Container Scanning |
Deploy |
Stage Lifecycle: Usable for most GitLab users (typically year 4) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
Continuous Delivery | |||||
Feature Flags | |||||
Release Orchestration | |||||
Environment Management | |||||
Auto DevOps | |||||
Deployment Management | |||||
Infrastructure as Code |
Monitor |
Stage Lifecycle: Not used at GitLab Inc. (typically year 1) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
Incident Management | |||||
On-call Schedule Management | |||||
Service Desk |
Govern |
Stage Lifecycle: Not used at GitLab Inc. (typically year 1) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
User Management | |||||
System Access | |||||
Audit Events | |||||
Compliance Management | |||||
Security Policy Management | |||||
Vulnerability Management | |||||
Dependency Management | |||||
Software Bill of Materials | |||||
Release Evidence |
Analyze |
|||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
Product Analytics Visualization | |||||
Metrics | |||||
Logging | |||||
Error Tracking | |||||
Tracing |
Manage |
Stage Lifecycle: Usable for most GitLab users (typically year 4) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
Integrations |
Systems |
Stage Lifecycle: Users of other tools start to switch (typically year 5) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
Omnibus Package | |||||
Cloud Native Installation | |||||
Geo-replication | |||||
Disaster Recovery |
Data Stores |
Stage Lifecycle: Users of other tools start to switch (typically year 5) |
||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
Groups & Projects | |||||
Global Search | |||||
Code Search |
ModelOps |
|||||
Category | Today | Q3 | Q4 | Q1 | Q2 |
Date | by 2023-10-31 | by 2024-01-31 | by 2024-04-30 | by 2024-07-31 | |
MLOps |
Learn how to make changes to categories and their maturity on our website handbook page.