---
layout: markdown_page
title: "GitLab Direction"
extra_css:
- maturity.css
---
## On this page
{:.no_toc}
- TOC
{:toc}
This page introduces the GitLab product vision, where we're headed over the next few years, and our plan to deliver over the next year.
## Vision
Our vision is to replace disparate DevOps toolchains with a [single application](/handbook/product/single-application/)
that is pre-configured to work by default across the entire DevOps lifecycle.
We aim to make it faster and easier for groups of contributors to deliver value
to their users, and we achieve this by enabling:
* Faster cycle time, driving an improved time to innovation
* Easier workflows, driving increased collaboration and productivity
Our solution [plays well with others](/handbook/product/#plays-well-with-others), works for teams
of any size and composition and for any kind of project, and provides ongoing [actionable feedback](/direction/#actionable-feedback)
for continuous improvement.
You can read more about the principles that guide our prioritization process in
our [product handbook](/handbook/product/#product-principles). You can also read
our [GitLab as a Product](/handbook/product/#gitlab-as-a-product)
section which describes the principles that are used to guide GitLab itself
forward.
### Background and history
* [Product Vision, Strategy, and 2020 Plan slides](https://docs.google.com/presentation/d/11fKMOWl6pVx-BCc6LXrHXfvRXZWU3USrEHSFWgpblL4/edit?usp=sharing)
* [The Product Vision Backstory](/blog/2018/10/09/gitlab-product-vision-back-story/)
* [The 2019 and Beyond Product Vision](/blog/2018/10/01/gitlab-product-vision/)
* [Product Vision, Strategy, and 2019 Plan slides](https://docs.google.com/presentation/d/19o720CqP9S-xRQoT9y8FF7DgtRxuJhQedaaQQQygYx8/edit)
* [GitLab's 2018 Product Vision: Prototype demo](/blog/2018/02/26/gitlabs-2018-product-vision/)
* [Beyond CI/CD: GitLab's DevOps vision](/blog/2017/10/04/devops-strategy/) (circa 2017)
### DevOps Stages
*[Image source](/images/press/devops-lifecycle.sketch)*
DevOps is a broad space with a lot of complexity. To manage this within GitLab,
we break down the [DevOps lifecycle](https://en.wikipedia.org/wiki/DevOps_toolchain)
into a few different [sections](/handbook/product/categories/#hierarchy), each with its own direction page you can review.
<% data.sections.each do |sectionKey, section| %>
<% line = "* **[#{section.name} Section Direction](#{section.direction})** - Includes the " %>
<% stages = data.stages.stages.select{|stageKey, stage| stage.section==sectionKey} %>
<% stageLinks = stages.map { |stageKey,stage| "[#{stage.display_name}](#{stage.direction})" } %>
<% line += stageLinks.to_sentence + " " + "stage".pluralize(stages.count) %>
<% if stages.count == 1 then %>
<% stages.each do |stageKey, stage| %>
<% groups = stage.groups.map { |groupKey, group| "[#{group.name}](#{group.direction})" } %>
<% line += ", which includes the " + groups.to_sentence + ' ' + "group".pluralize(groups.count) %>
<% end %>
<% end %>
<%= line %>
<% end %>
We are investing in the following manner across each stage:
- [Planning spreadsheet](https://docs.google.com/spreadsheets/d/e/2PACX-1vSyBNOX8DEtgx78ZIRlRXvPRPTIAywSdT1If-z5wmFE8U4WxHkIERf5DLhaYoSP_URPnX-zzbNyE7AC/pubhtml) with PM analysis of competition, Headcount with stage revenue, Headcount by category
- [Product categories](https://about.gitlab.com/handbook/product/categories/)
- [Maturity page](/direction/maturity/)
- [Backend hiring priorities](https://gitlab.com/gitlab-com/people-ops/hiring-processes/blob/master/Engineering/Backend/README.md)
- [Rolling 4 Quarters GitLab Hiring Plan](https://docs.google.com/spreadsheets/d/12mNijMwA8hIG5h3zV5JJ0oxsVh6xzk6-si0eT7L9mvM/edit#gid=1361884179) (internal only)
- [Finding headcount outside of your stage](https://about.gitlab.com/handbook/product/product-management/process/#prioritize-global)
### [Possible future stages](/direction/future-stages)
Possible future stages that are being considered can be found on our [Product stages, groups, and categories](https://about.gitlab.com/handbook/product/categories/#possible-future-stages) page
## 3-year Strategy
Product uses a few key concepts to talk about how we work:
* [Depth](#depth)
* [Breadth](#breadth)
* [Personas](#personas)
* [Application Types](#application-types)
* [Themes](#themes)
### Depth
We aim for product leadership in almost every area we compete in. We're
already there with:
* Source Code Management
* Continuous Integration
The next three we'll build up to best-in-class, lovable features are:
* [Project Management](/direction/project_management/)
* CD/Release Automation
* Application Security Testing
[Depth](/direction/depth) is about taking everything that's already `viable` and getting it through to `complete`, and eventualy to `lovable`.
<%= partial "direction/depth/sdlc" %>
### Breadth
We wouldn't be true to our ambition if we stopped with our current product
categories. For [breadth](/direction/breadth), we’re taking all the brand new, `planned` categories, as well as the existing, but `minimal` categories, and making them all `viable`.
<%= partial "direction/breadth/sdlc" %>
### Personas
Personas are the people we design for. We’ve started down the path of having developers, security professionals, and operations professionals as first-class citizens; letting each person have a unique experience tailored to their needs.
We want GitLab to be the main interface for all of these people. Show up at work, start your day, and load up GitLab. And that’s already happening.
But there are a ton of people involved with the development and delivery of
software. That is the ultimate GitLab goal - where everyone involved with
software development and delivery uses a single application so they are on the
same page with the rest of their team. We’ve recently launched the first
features for [Designers](/direction/designers) and soon we’ll have more for Product Managers. We’ll be
expanding to the business side, with [Executives](/direction/personas/executives) visibility and reporting. Maybe even Legal gets involved in license review. While we’re still calling
it DevOps, we’re really expanding the definition of DevOps, and delivering it
all as a single application.
Current Personas:
<% data.personas.each do |personaKey, persona| %>
<% end %>
### Application Types
The last prong is application types. There’s a bunch of things we’re great for, like cloud native web apps. And our customers have projects today that we could support better, like mobile apps. And then there’s a ton of stuff in the future to consider, like data science and ML.
Application types represent both different application types (web applications,
mobile apps) and architectures (monorepos, microservices). Gitlab continues to
deliver and replace the disparate DevOps toolchain for both static sites and
traditional web applications. These are two examples of application types. We're
actively investing in more robust support for new application types such as
cloud native and mobile apps, but we aren't done there. GitLab will expand to
enable collaboration on new application types.
See the [handbook](/handbook/product/application-types/) for more details or the current [maturity levels](/direction/maturity/#application-type-maturity).
Current Application Types:
<% data.application_types.each do |apptypeKey, apptype| %>
<% end %>
Future application types:
- Data science
- ML/AI
- Security research
- Gaming (LFS / Monorepo with many binaries)
### Themes
#### Trend Towards Consolidation
Continuing apace in 2019 after Microsoft's 2018 [acquisition of GitHub](https://blogs.microsoft.com/blog/2018/10/26/microsoft-completes-github-acquisition/), the trend to consolidate DevOps companies seems here to stay. In January 2019, [Travis CI was acquired by Idera](https://techcrunch.com/2019/01/23/idera-acquires-travis-ci/), and in February 2019 we saw [Shippable acquired by JFrog](https://techcrunch.com/2019/02/21/jfrog-acquires-shippable-adding-continuous-integration-and-delivery-to-its-devops-platform/). Atlassian and GitHub now both bundle CI/CD with SCM, alongside their ever-growing related suite of products. In January 2020, [CollabNet acquired XebiaLabs to build out their version of a comprehensive DevOps solution](https://xebialabs.com/company/press/collabnet-versionone-and-xebialabs-combine-to-create-integrated-agile-devops-platform/).
It's natural for technology markets go through stages as they mature: when a young technology is first becoming popular, there is an explosion of tools to support it. New technologies have rough edges that make them difficult to use, and early tools tend to center around adoption of the new paradigm. Once the technology matures, consolidation is a natural part of the life cycle. GitLab is in a fantastic position to be ahead of the curve on consolidation, but it's a position we need to actively defend as competitors start to bring more legitimately integrated products to market.
## 1-year Plan
For 2020, we have 5 key product themes we are focused on:
1. Enterprise Readiness: Make it easy for large enterprise customers to rapidly adopt and get value from GitLab. Relevant product direction themes include:
* [Enterprise ready GitLab management features](https://about.gitlab.com/direction/dev/#manage)
* [High availability Git and large repo support](https://about.gitlab.com/direction/dev/#create)
* [GitLab is easy to deploy and operate](https://about.gitlab.com/direction/enablement/#gitlab-is-easy-to-deploy-and-operate)
* [Consistently great user experience regardless of location or scale](https://about.gitlab.com/direction/enablement/#consistently-great-user-experience-regardless-of-location-or-scale)
* [Achieve enterprise compliance needs](https://about.gitlab.com/direction/enablement/#achieve-enterprise-compliance-needs)
1. Double down on strengths: Ensure our core product experience around Source Code Management and Continuous Integration remains best in class. Relevant product direction themes include:
* [Enhanced code review and realtime merge requests](https://about.gitlab.com/direction/dev/#create)
* [Git availability and performance and large repo support](https://about.gitlab.com/direction/dev/#create)
* [Speedy, reliable pipelines](https://about.gitlab.com/direction/ops/#speedy-reliable-pipelines)
* [Multi-platform support](https://about.gitlab.com/direction/ops/#multi-platform-support)
* [Single application CI/CD](https://about.gitlab.com/direction/ops/#single-application-cicd)
* [Do powerful things easily](https://about.gitlab.com/direction/ops/#do-powerful-things-easily)
1. World-Class Security for DevSecOps: Deliver fully integrated security experience, allowing customers to adapt security testing and processes to developers (and not the other way around). Relevant product direction themes include:
* [Security is a team effort](https://about.gitlab.com/direction/secure/#security-is-a-team-effort)
* [Shift left. No, more left than that](https://about.gitlab.com/direction/secure/#shift-left-no-more-left-than-that)
* [Shift right. Yes, right into operations](https://about.gitlab.com/direction/secure/#shift-right-yes-right-right-into-operations)
* [Provide actionable intelligence to ensure data-driven decisions](https://about.gitlab.com/direction/secure/#provide-active-intelligence-to-enable-data-driven-decisions)
* [Bring your own security tools](https://about.gitlab.com/direction/secure/#byot---bring-your-own-security-tools)
1. Compete in Planning: Enable DevOps teams to rely solely on GitLab for all project and portfolio management needs. Relevant product direction themes include:
* [Improved Jira import, Kanban boards, roadmaps, requirements management, strategic planning, and reporting](https://about.gitlab.com/direction/dev/#plan)
1. Compete in Ops: Enable today's modern best-practices in operations without the burden of specialized teams, multiple tools and heavy workflows. Relevant product direction themes include:
* [Infrastructure and Observability as Code](https://about.gitlab.com/direction/ops/infrastructure-and-observability-as-code)
* [Smart feedback loop](https://about.gitlab.com/direction/ops/#smart-feedback-loop)
* [Operations for all](https://about.gitlab.com/direction/ops/#operations-for-all)
* [No-Ops](https://about.gitlab.com/direction/ops/#no-ops)
## Maturity
As we add new categories and stages to GitLab, some areas of the product will be deeper and more mature than others. We publish a
list of the categories, what we think their maturity levels are, and our plans to improve on our [maturity page](/direction/maturity/).
## Scope
We try to prevent maintaining functionality that is language or platform
specific because they slow down our ability to get results. Examples of how we
handle it instead are:
1. We don't make native mobile clients, we make sure our mobile web pages are great.
1. We don't make native clients for desktop operating systems, people can use [Tower](https://www.git-tower.com/) and for example GitLab was the first to have merge conflict resolution in our web applications.
1. For language translations we [rely on the wider community](https://docs.gitlab.com/ee/development/i18n/translation.html).
1. For Static Application Security Testing we rely on [open source security scanners](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks).
1. For code navigation we're hesitant to introduce navigation improvements that only work for a subset of languages.
1. For [code quality](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality_diff.html) we reuse Codeclimate Engines.
1. For building and testing with [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) we use Heroku Buildpacks.
Outside our scope are Kubernetes and everything it depends on:
1. **Network** (fabric) [Flannel](https://github.com/coreos/flannel/), Openflow, VMware NSX, Cisco ACI
1. **Proxy** (layer 7) [Envoy](https://envoyproxy.github.io/), [nginx](https://nginx.org/en/), [HAProxy](http://www.haproxy.org/), [traefik](https://traefik.io/)
1. **Ingress** [(north/south)](https://networkengineering.stackexchange.com/a/18877) [Contour](https://github.com/heptio/contour), [Ambassador](https://www.getambassador.io/),
1. **Service mesh** [(east/west)](https://networkengineering.stackexchange.com/a/18877) [Istio](https://istio.io/), [Linkerd](https://linkerd.io/)
1. **Container Scheduler** we mainly focus on Kubernetes, other container schedulers are: CloudFoundry, OpenStack, OpenShift, Mesos DCOS, Docker Swarm, Atlas/Terraform, [Nomad](https://nomadproject.io/), [Deis](http://deis.io/), [Convox](http://www.convox.com/), [Flynn](https://flynn.io/), [Tutum](https://www.tutum.co/), [GiantSwarm](https://giantswarm.io/), [Rancher](https://github.com/rancher/rancher/blob/master/README.md)
1. **Package manager** [Helm](https://github.com/kubernetes/helm), [ksonnet](http://ksonnet.heptio.com/)
1. **Operating System** Ubuntu, CentOS, [RHEL](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux), [CoreOS](https://coreos.com/), [Alpine Linux](https://alpinelinux.org/about/)
During a presentation of Kubernetes Brendan Burns talks about the 4 Ops layers
at [the 2:00 mark](https://youtu.be/WwBdNXt6wO4?t=120):
1. Application Ops
1. Cluster Ops
1. Kernel/OS Ops
1. Hardware Ops
GitLab helps you mainly with application ops. And where needed we also allow you
to monitor clusters and link them to application environments. But we intend to
use vanilla Kubernetes instead of something specific to GitLab.
Also outside our scope are products that are not specific to developing,
securing, or operating applications and digital products.
1. Identity management: Okta and Duo, you use this mainly with SaaS applications
you don't develop, secure, or operate.
1. SaaS integration: Zapier and IFTTT
1. Ecommerce: Shopify
In scope are things that are not mainly for SaaS applications:
1. Network security, since it overlaps with application security to some extent.
1. Security information and event management (SIEM), since that measures
applications and network.
1. Office productivity applications, since
["We believe that all digital products should be open to contributions, from legal documents to movie scripts and from websites to chip designs"](/company/strategy/#why)
## Quarterly Objectives and Key Results (OKRs)
To make sure our goals are clearly defined and aligned throughout the
organization, we make use of OKR's (Objective Key Results). Our [quarterly Objectives and Key Results](/company/okrs/)
are publicly viewable.
## Your contributions
GitLab's direction is determined by GitLab the company, and the code that is
sent by our [contributors](http://contributors.gitlab.com/). We continually
merge code to be released in the next version. Contributing is the best way to
get a feature you want included.
On [our issue tracker for CE][ce-issues] and [EE][ee-issues], many requests are
made for features and changes to GitLab. Issues with the [Accepting Merge
Requests] label are pre-approved as something we're willing to add to GitLab. Of
course, before any code is merged it still has to meet our [contribution
acceptance criteria].
[ce-issues]: https://gitlab.com/gitlab-org/gitlab-ce/issues
[ee-issues]: https://gitlab.com/gitlab-org/gitlab-ee/issues
[Accepting merge requests]: https://gitlab.com/gitlab-org/gitlab-ce/issues?state=opened&label_name=Accepting+merge+requests
[contribution acceptance criteria]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#contribution-acceptance-criteria
## How we plan releases
At GitLab, we strive to be [ambitious](/handbook/product/#how-this-impacts-planning),
maintain a strong sense of urgency, and set aspirational targets with every
release. The direction items we highlight in our [kickoff](/handbook/product/product-management/process/#kickoff-meetings)
are a reflection of this ambitious planning. When it comes to execution we aim
for
[velocity over predictability](/handbook/engineering/#velocity-over-predictability).
This way we optimize our planning time to focus on the top of the queue and
deliver things fast. We schedule 100% of what we can accomplish based on past [throughput](/handbook/engineering/management/throughput/)
and availability factors (vacation, contribute, etc.).
See our [product handbook on how we prioritize](/handbook/product/product-management/process/#prioritization).
## Previous releases
On our [releases page](/releases/) you can find an overview of the most
important features of recent releases and links to the blog posts for each
release.
## Upcoming releases
GitLab releases a new version [every single month on the 22nd](/blog/2015/12/07/why-we-shift-objectives-and-not-release-dates-at-gitlab). You can find the
major planned features for upcoming releases on our [upcoming releases page](/upcoming-releases/) or see the [upcoming features for paid tiers](/direction/paid_tiers).
Note that we often move things around, do things that are not listed, and cancel
things that _are_ listed.
## Moonshots
See [moonshots](/direction/moonshots/).
### Actionable feedback
Deployments should never be fire and forget. GitLab will give you immediate
feedback on every deployment on any scale. This means that GitLab can tell you
whether performance has improved on the application level, but also whether
business metrics have changed.
Concretely, we can split up monitoring and feedback efforts within GitLab in
three distinct areas: execution (cycle analytics), business and system feedback.
#### Business feedback
With the power of monitoring and an integrated approach, we have the ability to
do amazing things within GitLab. GitLab will be able to automatically test
commits and versions through feature flags and A/B testing.
Business feedback exists on different levels:
* Short term: how does a certain change perform? Choose A/B based on data.
* Medium term: did a particular new feature change conversions, engagement
* Long term: how do larger efforts relate to changes in conversations, engagement, revenue
- [A/B Testing of branches](https://gitlab.com/gitlab-org/gitlab-ee/issues/117)
#### Application feedback
Your application should perform well after changes are made. GitLab will be able
to see whether a change is causing errors or performance issues on application
level. Think about:
* Response times of e.g. a backend API
* Error rates and occurrences of new bugs
* Changes in API calls
#### System feedback
We can now go beyond CI and CD. GitLab will able to tell you whether a change
improved performance or stability. Because it will have access to both
historical data on performance and code, it can show you the impact of any
particular change at any time.
System feedback happens over different time windows:
* Immediate: see whether changes influence availability and alert if they do
* Short-medium term: see whether changes influence system metrics and performance
* Medium-Long term: did a particular effort influence system status
- Implemented: [Performance Monitoring](https://docs.gitlab.com/ee/administration/monitoring/performance/introduction.html)
- [Status monitoring and feedback](https://gitlab.com/gitlab-org/gitlab-ce/issues/25555)
- [Feature monitoring](https://gitlab.com/gitlab-org/gitlab-ce/issues/24254)
#### Execution feedback & Cycle Analytics
GitLab is able to speed up cycle time for any project. To provide feedback on
cycle time GitLab will continue to expand cycle analytics so that it not only
shows you what is slow, it’ll help you speed up with concrete, clickable
suggestions.
- [Cycle Speed Suggestions](https://gitlab.com/gitlab-org/gitlab-ce/issues/25281)
### ML/AI at GitLab
Machine learning (ML) through neural networks is a really great tool to solve hard to define, dynamic problems.
Right now, GitLab doesn't use any machine learning technologies, but we expect to use them [in the near future](https://gitlab.com/groups/gitlab-org/-/issues?label_name%5B%5D=ML%2FAI)
for several types of problems.
#### Signal / noise separation
Signal detection is very hard in a noisy environment. GitLab intends to use
ML to warn users of any signals that stand out against the background noise in several features:
- security scans, notifying the user of stand-out warnings or changes
- error rates and log output, allowing you to rollback / automatically rollback a change if the network notices aberrant behavior
#### Recommendation engines
Automatically categorizing and labelling is risky. Modern models tend to overfit, e.g. resulting
in issues with too many labels. However, similar models can be used very well in combination
with human interaction in the form of recommendation engines.
- [suggest labels to add to an issue / MR (one click to add)](https://gitlab.com/tromika/gitlab-issues-label-classification)
- suggest a comment based on your behavior
- suggesting approvers for particular code
#### Smart behavior
Because of their great ability to recognize patterns, neural networks are an excellent
tool to help with scaling, and anticipating needs. In GitLab, we can imagine:
- auto scaling applications / CI based on past load performance
- prioritizing parallelized builds based on the content of a change
#### Code quality
Similar to [DeepScan](https://deepscan.io/home/).
#### Code navigation
Similar to [Sourcegraph](https://about.sourcegraph.com/).
#### Audit events
Identifying anomalous activity within audit events systems can be both challenging and valuable. This identification is difficult because audit events are raw, objective data points and must be interpreted against an organization's company policies. Knowing about anomalous behavior is valuable because it can allow GitLab administrators and group owners to proactively manage undesireable events.
This a difficult [problem to solve](https://about.gitlab.com/direction/manage/audit-events/#problems-to-solve), but can help to drastically reduce the overhead of managing risk within a GitLab environment.