Gitlab hero border pattern left svg Gitlab hero border pattern right svg

GitLab Direction

On this page


Our vision is to replace disparate DevOps toolchains with a 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:

Our solution plays well with others, works for teams of any size and composition and for any kind of project, and provides ongoing actionable feedback for continuous improvement.

You can read more about the principles that guide our prioritization process in our product handbook.

Background and history

DevOps stages

DevOps Lifecycle

DevOps is a broad space with a lot of complexity. To manage this within GitLab, we break down the DevOps lifecycle into a few different stages, each with its own strategy page you can review. We are investing in the following manner across each stage:



Overall visibility and insight into what's happening within GitLab


Planning capabilities to keep your team synchronized and moving in the right direction


Create, view, and manage code and project data through powerful tooling



Keep strict quality standards for production code with automatic testing and reporting


Manages the packages you build and depend on in your software delivery process


Continuous delivery and orchestration of your releases to your users



Automation to configure your applications and infrastructure


Application Performance Monitoring (APM) Monitor system behavior to understand the impact of changes on your system

Debugging and Health Triage, respond, resolve and prevent incidents to minimize downtime


Security capabilities, directly integrated into your development lifecycle


Defend your apps and infrastructure from security intrusions

Enablement Groups

Supporting the stages in the DevOps lifecycle, there are additional Enablement groups, again with their own direction pages:




Growth Groups

Supporting the stages in the DevOps lifecycle, there are additional Growth groups, again with their own direction pages:








Product uses a few key concepts to talk about how we work:

Product Strategy


We aim for market leadership in every category we compete in. We're already there with:

For FY20, and we'll build best-in-class, lovable features in our four focus areas:

Additionally, our FY20 goals include moving these categories to complete.


We wouldn't be true to our ambition if we stopped with our current product categories. Across our existing DevOps stages we'll continue to rapidly expand with new categories.

New Categories

For more information, check out our epics below:











We are additionally prioritizing getting these categories from Minimal to Viable.


GitLab enables everyone to contribute. Our platform can be used by all people contributing to digital content.

Full Scope

We've already built great workflows and dashboards for:

We are investing in our relatively new roles:

We plan to expand to more roles in FY2020:

Other candidates:

Gitlab Devops

Application Types

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. More details.

In FY20, we're targeting:

Future application types:

Company Initiatives

We are also tracking big initiatives for the entire company or for the application at a holistic level that impact the product. These items have their own planning and goals, and typically bridge several (and in some cases even all) of the stages in the product. Some have formal working groups. There are other formal working groups that are not mentioned here as this list focuses on efforts that Product is directly involved with.

Enterprise editions

GitLab comes in 4 editions:


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.


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.
  2. We don't make native clients for desktop operating systems, people can use Tower and for example GitLab was the first to have merge conflict resolution in our web applications.
  3. For language translations we rely on the wider community.
  4. For Static Application Security Testing we rely on open source security scanners.
  5. For code navigation we're hesitant to introduce navigation improvements that only work for a subset of languages.
  6. For code quality we reuse Codeclimate Engines.
  7. For building and testing with Auto DevOps we use Heroku Buildpacks.

Outside our scope are Kubernetes and everything it depends on:

  1. Network (fabric) Flannel, Openflow, VMware NSX, Cisco ACI
  2. Proxy (layer 7) Envoy, nginx, HAProxy, traefik
  3. Ingress (north/south) Contour, Ambassador,
  4. Service mesh (east/west) Istio, Linkerd
  5. Container Scheduler we mainly focus on Kubernetes, other container schedulers are: CloudFoundry, OpenStack, OpenShift, Mesos DCOS, Docker Swarm, Atlas/Terraform, Nomad, Deis, Convox, Flynn, Tutum, GiantSwarm, Rancher
  6. Package manager Helm, ksonnet
  7. Operating System Ubuntu, CentOS, RHEL, CoreOS, Alpine Linux

During a presentation of Kubernetes Brendan Burns talks about the 4 Ops layers at the 2:00 mark:

  1. Application Ops
  2. Cluster Ops
  3. Kernel/OS Ops
  4. 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.
  2. SaaS integration: Zapier and IFTTT
  3. 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.
  2. Security information and event management (SIEM), since that measures applications and network.
  3. 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"

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 are publicly viewable.

Your contributions

GitLab's direction is determined by GitLab the company, and the code that is sent by our contributors. 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 and EE, 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.

How we plan releases

At GitLab, we strive to be ambitious, maintain a strong sense of urgency, and set aspirational targets with every release. The direction items we highlight in our kickoff are a reflection of this ambitious planning. When it comes to execution we aim for 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 and availability factors (vacation, contribute, etc.).

See our product handbook on how we prioritize.

Previous releases

On our releases page 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. You can find the major planned features for upcoming releases on our upcoming releases page.

Note that we often move things around, do things that are not listed, and cancel things that are listed.


Moonshots are big hairy audacious goals that may take a long time to deliver.


Starter features are available to anyone with an Enterprise Edition subscription (Starter, Premium, Ultimate).


Premium features are only available to Premium (and Ultimate) subscribers.


Ultimate is for organizations that have a need to build secure, compliant software and that want to gain visibility of - and be able to influence - their entire organization from a high level. Ultimate features are only be available to Ultimate subscribers.

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:

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:

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:

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.

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 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:

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.

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:

Code quality

Similar to DeepScan.

Code navigation

Similar to Sourcegraph.

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, but can help to drastically reduce the overhead of managing risk within a GitLab environment.