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

Section Direction - Ops

Ops Overview

Source

Ops Section Overview

Composition

The Ops Section comprises the Verify, Package,Release,Configure and Monitor stages of the DevOps lifecycle. Market analysts (internal - i) often describe these stages as automated software quality (ASQ, partially analgous to Verify, Package and Release) IT automation and configuration management (ITACM, analogous to Configure) and IT operations management (ITOM, partially analogous to Monitor).

In some contexts, "ops" refers to operators. Operators were the counterparts to Developers represented in the original coining of the term DevOps. That definition highlighted the rift between the two groups and a need for collaboration. At Gitlab, we use "ops" to mean operations - any component of the software delivery value stream after a developer commits code. Our developer first perspective means our use of the word ops is focused on enabling developers to configure tools and perform operations tasks first. We have ambitious plans to support operators in the future.

Market

The total addressable market (TAM) for DevOps tools targeting these stages was $3.2B in 2018 and is expected to grow to $7.6B by 2022 (18.8% CAGR) (i). This is a deep value pool and represents a significant portion of GitLab's expanding addressable market as organizations further adopt DevOps and developer focused ops tools account for a larger share of a market which traditionally targets Architects, System Admin and Operator personas.

The market is well established (i) but the participants are evolving rapidly. Existing leaders in single stages of the DevOps lifecycle are expanding towards a complete DevOps delivery platform via acquisition and product development. These existing leaders run the gamut from GitHub with their strong position in the Create stage, to Splunk with their strong position in Monitor. All are pivoting to pursue an single DevOps platform strategy.

Expanded market players such as GitHub are taking market share from traditional participants like CloudBees in the Verify stage. In the Package stage, JFrog is expanding their leadership position in artifact repositories into other stages of the DevOps lifecycle. In the Release stage Spinnaker is new open-source, fast growing entrant enabling collaborative CI/CD workflows and taking market share from traditional Application Release Orchestration vendors. Splunk, New Relic and Datadog are dominating market share in the Monitor stage and fiercely competing to be a central devops platform. IBM (+RedHat), Hashicorp, Puppet and Chef splitting a large chunk of the fragmented market in the Configure stage.

Current Position

Despite many strong players, GitLab's market share in the Ops section is strong, especially in the Verify, Package, Release and Configure stages. For the configure and monitor stages, our unique perspective as a single and complete devops application positions us for growth. Our customers utilize many Ops Section stages today. Primarily they:

Our current R&D investment in Ops Section stages is large. The maturity of each stage and category can be found in our maturity page. Our investment in the Ops section is is critical to both enabling next steps in enterprise users continued DevOps maturity journey, and as we continue to create the first complete DevOps tool. Doing so enables early adopters to recognize the benefit of a single application.

We would appreciate your feedback on this direction page. Please take our survey, email Kenny Johnston or propose an MR to this page!

Challenges

GitLab is competing in a new market of value stream delivery platforms (i - Gartner). We were an early entrant in this market before it was defined but there are many, and will be more fast followers. Key players include large established tech firms (Microsoft) as well as newly consolidated platforms from aquisition (JFrog, CollabNet VersionOne/XebiaLabs).

Beyond the key players, there is also rapid innovation in new technologies making for a market where there is both proliferation of new technology, and consolidation of the winning technologies into comprehensive platform players. Ease of deployment for CI/CD and operational tools has aided this expansion. Developers and operations teams can easily instrument and utilize new technologies alongside their existing software development pipelines with less risk, and in quicker time frames than under previous models where it required diligent planning and months of installation and configuration.

Competing tools are marketed as stand-alone point solutions while GitLab's capabilities will shine when customers use other stages of GitLab. This can create a narrow funnel for adoption with potential users coming only from the segment of the market already using, or willing to use, other stages of GitLab rather than broad-based market fit. Without developing more landing spots for new users of GitLab, this smaller adoption funnel will affect our rate of learning.

Few companies have been able to successfully bridge between Developer and Operator personas. Building tools that satisfy both sets of jobs-to-be-done is difficult. Without deeply understanding new personas and tasks, market entrants end up with a checklist of modules that don't represent a cohesive and improved experience for users.

In recent years we've seen the emergence of large public cloud infrastructure providers moving from a focus on infrastructure services for operators towards developer tools. These providers could challenge current notions of multi-cloud by creating great, integrated experiences in their tools for developers to create, verify, and deploy applications to the providers' infrastructure.

Outside of market challenges we have some internal ones as well. In general, we are not dogfooding the Release, Monitor and Configure stage features sufficiently. This has the effect of slowing our rate of learning, and putting us in the position of not having immediate real-world validation of our product initiatives.

Opportunities

Given these challenges, here are some key opportunities we must take advantage of:

3 Year Strategy

GitLab's Ops strategy follows that of GitLab's company strategy. Just like our company mission, we will enable everyone to contribute not just via application code, but via other digital artifacts that increasingly define the performance, reliability, and resilience of the world's software. We will pursue that mission and capitalize on the opportunities (developer buyer power, IT skills gaps, a move towards Kubernetes, and our roots in source-control and CI) listed above by utilizing dual-flywheel approach. This approach starts with attracting developers performing devops tooling and operations tasks to our Core (FOSS). As we build killer tools for them we will utilize their feedback to drive community and product improvements. This will in turn generate revenue for higher product tiers and additional investment for supporting the platform and ops teams which support modern development teams.

We'll do this by enabling easy-to-discover workflows that support doing powerful, complex actions with a minimum of manual configuration. We want to take advantage of our single application so that, while each team may have their own views or dashboards in the product that support their day to day, the information about what is deployed where is available everywhere and to everyone, embedded naturally into the product where it's relevant. For example, a person thinking about upcoming releases may interact mostly with an environment-based overview that helps them see upcoming changes and alerts as they flow through environments, but that same information exists everywhere it is relevant:

The end result is that even complex delivery flows become part of everyone's primary way of working. There isn't a context shift (or even worse, a switch into a different tool) needed to start thinking about delivery or operations - that information is there, in context, from your first commit. The centerpiece of this strategy is our Get Things Done Easily theme.

Market Predictions

In three years the Ops market will:

GitLab Goals

As a result, in three years, the Ops stages in Gitlab will:

Themes

Our direction for Ops is to enable today's modern best practices in operations without the burden of specialized teams, multiple tools, and heavy workflows that are the largest barriers to adoption in these stages of the DevOps lifecycle. Our goal is to empower DevOps teams to own their code in production and have the tools to contribute not just to application feature development, but to the characteristics of their applications as experienced by their end-users.

Get Things Done Easily

One of the core principles of GitLab is the idea that we want to ensure the powerful things you can achieve with GitLab are easy to do, without railroading to a particular solution. This helps us remain flexible and avoid hewing too closely to a specific technology solution, ensuring we retain our flexibility to embrace future innovation. This includes providing modern and powerful project templates for emerging technologies like ML/AI, and for popular but sometimes complex pipelines like ones for mobile application development and, in general, improving onboarding for the product.

An interesting measure for this is how long it takes to get to your first green build from the time you create your project, for both new and seasoned pipeline users. We are going to start tracking this as a success metric for how easy it is to get in and get your work done; GitLab's built-in functionality will make this as quick and easy as possible.

Related Epics (* indicates an important growth driver for this category):

Progressive Delivery

Progressive Delivery is a set of emerging CD best practices, oriented around being able to control and monitor deployments incrementally over time, and in an automated and safe way. It takes Continuous Delivery to the next level by providing more options around how and when different users get access to your new features, making software delivery a continuous activity, rather than frequent but punctuated moments in time.

Additional articles on Progressive Delivery can be found on the LaunchDarkly blog, RedMonk and The New Stack, as well as our own blog posts highlighting Feature Flags and Review Apps.

Related Epics (* indicates an important growth driver for this category):

Multi-Platform Support

Improving the ability and options available for GitLab to support multiple platforms, such as Windows, Mac, ARM, and even mainframes, GPUs, TPUs, FPGAs, RISC-V, and so on, is a top priority because it enables more of our users to take advantage of the GitLab single application. A lot of the work around adding platforms is related to the GitLab Runner, which we want you to be able to run literally anywhere, and build any kind of code. You can see more about what we plan to do there on the Runner direction page. We will be adding not just support for new platforms from bring-your-own-runner, but adding these to our shared fleet as well.

Truly being multi-platform also means making sure that GitLab interacts well with other platforms and tools you use as part of your DevOps ecosystem. One important element of this for CI/CD in particular is making sure that GitLab CI/CD remains a viable, performant option even when using external repositories, but also means for example supporting different testing platforms, packaging systems, or other automation tools that tend to be platform-heavy or even platform-specific.

Related Epics (* indicates an important growth driver for this category):

Single Application

DevOps tooling continues its trend towards consolidation, driven by exhaustion from the administrative effort needed to wire individual solutions together in order to get any benefit, and still never quite achieving a well-integrated user experience. Point solutions are struggling because they suffer from the fundamental problem that Ops (and especially CI/CD tooling) is not an island: in order to compete effectively, they are forced to maintain integrations with various stacks, which is expensive in terms of focus and results that they are unable to innovate as fast as competitors that are providing a unified solution. It's a priority for us that we retain flexibility for integrations if unbundling becomes a trend, or a high quality point solution emerges within any segment, but we can do this in a way that still takes advantage of our unified platform where available, and overall right now it's clear that our approach is winning.

In the end, our single application solution is what will ensure that GitLab is a Robot Cat instead of a Sheepdog. By embedding Ops workflows naturally into everyone's workflows, as a first-class part of working with issues, source control, merge requests, etc., Ops isn't a box under someone's desk that nobody knows how to work while on vacation - it's a part of how everyone works together, and the glue that binds everyone around actually delivering.

Related Epics (* indicates an important growth driver for this category):

Speedy, Reliable Pipelines

GitLab CI/CD was built from the ground up with speed and scalability in mind. This is reflected both in the product design as well as product vision (automated testing, testing all the things). To enable our users to go from monthly shipping releases to truly enabling continuous delivery, everything that we do must be concerned with the scalability and speed of continuous integration and testing. Not that sword fighting on office chairs isn't fun, but we do want people to be able to contribute at the speed of development. We will achieve this through automated tuning where possible, and faster feedback on potential issues where not.

Wall clock time for a pipeline is an important measure here. You feel this many times every day - when you make a commit and a pipeline starts, but you need to go have lunch before you see the result, that's not fun for anyone. Issues like our auto-determining the test parallelization factor and running tests likely to fail first represent how we want GitLab CI/CD to automatically find and solve these problems for you. We are building more speed into the workflow itself with features like the dependency proxy to help speed up the tax you you pay on every job invocation setting up the environment, fetching dependencies, and so on.

Related Epics (* indicates an important growth driver for this category):

Compliance as Code & Secure Secrets

Compliance as Code is the idea that requirements for auditing and compliance teams can be collected with zero additional cognitive load from developers and other team members participating in software delivery. Because GitLab has an end-to-end view of the artifacts that are associated with releases (issues, merge requests, feature flags, and so on) we are uniquely positioned to provide a comprehensive view of compliance-related activity, collected on an ongoing basis throughout the build, test, and release process. Our vision here can be found in our strategy page for Release Evidence.

In addition to collecting compliance evidence along the path to production, our plan is to improve the way GitLab pipelines interact with secure secrets, typically held in a Vault or other secrets store. Our plan is to first allow GitLab to integrate with your existing Vault, implemented via gitlab#28321. In the future, however, we have a broader vision for bundling Vault with GitLab and making secrets management a part of the GitLab product in general; this will expand to include storing GitLab's own secrets in an external Vault.

Related Epics (* indicates an important growth driver for this category):

Infrastructure and Observability as Code

There have been two major trends impacting operations; these are essential to seeding the DevOps transformation within teams. They are Infrastructure as Code (IAC) and Observability as Code (OAC).

Infrastructure as Code

IAC provides DevOps teams with a method to maintain consistency with the infrastructure their applications run on. The best practices defined in IAC prevent configuration drift, and allow teams to maintain consistent performance and security characteristics without the need for ongoing manual intervention.

IAC was made possible by the availability of rapidly deployed cloud infrastructure (IaaS platforms), and the corresponding buildup of tools to enable generic usage and consistent deployment to that infrastructure (Container Management Platforms).

With our roots as a source code management system, we will build on our existing workflows for code management, and extend our ability to define and manage infrastructure configuration in your project repositories so you can achieve reliability and consistency in your application.

As examples, GitLab will:

Observability and Operations as Code

Observability is a measure of your application which defines how well you can understand the state of your production system from its external outputs. The more observable your application is, the more reliably you can operate it, both manually and through automation. Our vision is to allow you to define your observability and operational automation in code, alongside your application code. Whether that is the configuration of dashboards, metrics, alerts, runbooks, automation scripts or incident issues - GitLab will source-control those configurations and ensure they are reliably deployed to your production systems.

As examples, GitLab will:

Smart Feedback Loop

Defining your infrastructure, observability, and operations as code is just the first step. The real magic happens when you rapidly iterate on those definitions. As a single-application for the entire DevOps lifecycle GitLab completes what is commonly a major gap in the DevOps loop - the feedback from ops back into planning.

Our vision is to provide not just an easy ability to identify, suggest, complete, and deploy changes to your production system, but also enable new insights that other tools can't. During incident response, GitLab can quickly identify the last deployed commit, lines of code changed, and author to guide the response to the right place. During deployment, GitLab can quickly tell you if your production system is already out-of-bounds from defined service-level indicator (SLI) metrics and roll back. During post-mortems, GitLab can suggest runbook or alert changes. We are very excited about enabling DevOps teams with these smart additions.

As examples, GitLab will:

Operations for All

Truly integrated DevOps teams are difficult to create. While large organizations have the budget to staff dedicated teams with roles like "Cost Optimization Engineer" and "Site Reliability Engineer" smaller teams require "Jack of All Trades" engineers.

Our vision at GitLab is that everyone can contribute, and that small teams, without specialization, can leverage and adopt the same tools as those in larger organizations. By building on our preference for convention over configuration, we can take the guess work out of operations. We will enable you and your team to quickly build a production application and iterate on it. We'll make it easy for teams to start from modern operations practices where you avoid alert fatigue by detecting real user events and are able to resolve like a pro. Not just on its features, but on the overall experience delivered to your users. Rapidly.

As examples, GitLab will:

No-Ops

While many teams will continue to employ operations best practices, there is a growing movement to use stricter conventions to reduce the need for operations tasks almost entirely. We'll continue to support this pattern via our investment in Auto DevOps, Serverless and PaaS iniatives.

At GitLab we believe more and more organizations will adopt centralized platform teams to manage and provide infrastructure to their development teams. By providing useful tools for those platform teams to function, we can assist them in reducing the operational burden on their development teams.

As examples, GitLab will:

Who is it for?

GitLab identifies who our Monitor and Configure stage features are built for utilizing the following categorization. We list our view of who we will support when in priority order.

Today

To capitalize on the opportunities listed above, the Ops section has features that make it useful to the following personas today.

  1. 🟩 Developer / DevOps Engineer
  2. 🟩 Cloud-Native Applications
  3. 🟨 Container Platform Teams
  4. 🟨 DevOps teams deploying to legacy infrastructure
  5. ⬜️ Ops Teams
  6. ⬜️ Central IT / System Admins

Medium Term (1-2 years)

As we execute our 3-year strategy, our medium term (1-2 year) goal is to provide a single application that enables collaboration between cloud native development and platform teams.

  1. 🟩 Developer / DevOps Engineer
  2. 🟩 Cloud-Native Applications
  3. 🟩 Container Platform Teams
  4. 🟩 DevOps teams deploying to legacy infrastructure
  5. 🟨 Ops Teams
  6. ⬜️ Central IT / System Admins

Critical Jobs to Be Done

GitLab will focus on the jobs to be done (JTBD) found in the workflows identified in the Configure and Monitor stages.

The most critical are:

One Year Plans

Ops Section Plan

In the next 12 months the Monitor and Configure stages must focus on:

In doing so, over the next 12 months we will choose NOT to:

Acquisition Plan

GitLab considers acquisitions as a key part of our investment in expanding the breadth of GitLab. The Monitor and Configure stages have a higher appetite for acquisition. Over the next year, GitLab is interested in acquisitions that fill gaps in our current set of new and minimal categories in the Configure and Monitor stages. There are also some other unnamed categories which fulfill our themes above that we would consider acquisitions in. Those include:

Top priorities:

  1. Observability - Tools that immediately increase our capabilities in tracing and digital experience management are a top priority. GitLab is immediately focused on improving the out-of-the-box experience for instrumenting and setting up triage workflows of users' applications.
  2. Smart Feedback Loop - Tools that enable the continuous improvement of applications via efficient feedback loops from production to the Plan stage, including product telemetry, user forums, suggestion mechanisms, and real-user monitoring. This is our second priority because it is a critical part of the DevOps process, and GitLab has limited to no capabilities or planned categories today.

Additional options:

Useful Resources

Below are some additional resources to learn more about Ops:

Stages and Categories

The Ops section is composed of five stages, each of which contains several categories. Each stage has an overall strategy statement below, aligned to the themes for Ops. Each category within each stage has a dedicated vision page plus optional documentation, marketing pages, and other materials linked below.

Verify

The three year goals of the Verify group (high-level roadmap; SMAU (Stage Monthly Active Users) dashboard) are:

  1. Be the tool of choice for groups that want to reduce their lead time for changes to under an hour. Part of how we will achieve this is by taking CI/CD analytics to the next level.
  2. Provide 100% automated setup, configuration, scaling, and management of GitLab Runners for medium to large enterprises.
  3. Make ML/AI workflows easier, including features like adding the ability to install industry leading applications like Kubeflow to your Kubernetes clusters.

The details of how we'll achieve different elements of this can be found in the individual category pages below:

Continuous Integration (CI)

Gain the confidence to ship at blistering speed and immense scale with automated builds, testing, and out-of-the-box security to verify each commit moves you forward. This category is at the "lovable" level of maturity.

Learn moreDocumentationDirection

GitLab Runner

GitLab Runner is the execution agent that is used to run your CI jobs and send the results back to GitLab. This category is at the "lovable" level of maturity.

DocumentationDirection

Jenkins Importer

The Jenkins Importer helps unblock teams from migrating to GitLab CI. This category is planned, but not yet available.

Direction

Code Quality

Automatically analyze your source code to surface issues and see if quality is improving or getting worse with the latest commit. This category is at the "minimal" level of maturity.

DocumentationDirection

Code Testing and Coverage

Code testing and coverage ensure that individual components built within a pipeline perform as expected, and are an important part of a Continuous Integration framework. This category is at the "minimal" level of maturity.

DocumentationDirection

Load Testing

Be confident in the performance of your changes by ensuring that they are validated against real world load scenarios. This category is planned, but not yet available.

Direction

Web Performance

Ensure performance of your software in-browser using automated web performance testing. This category is at the "minimal" level of maturity.

DocumentationDirection

Usability Testing

Testing to ensure usability flows work and are actually understandable and valuable to your users. This category is at the "minimal" level of maturity.

DocumentationDirection

Accessibility Testing

Beyond being a compliance requirement in many cases, accessibility testing is the right thing to do. This category is planned, but not yet available.

DocumentationDirection

Merge Trains

Keeping master green and ensuring the stability of collaboration on branches is vitally important. GitLab has introduced Merge Trains as an important way to accomplish this. This category is at the "viable" level of maturity.

DocumentationDirection

Package

The three year goals of the Package group (high-level roadmap; SMAU (Stage Monthly Active Users) dashboard are:

  1. Build a set of features that, within three years, will allow ninety percent of our customers to store all of their packages in GitLab.
  2. Unify the Container Registry and the Package Registry to create a seamless user experience for building, testing and releasing code. We will achieve this through improving the usability of our existing registries and standardizing authentication and permissions for each package manager, as well as creating visibility and transparency into the Package and Container Registry itself.
  3. Work our customers and the GitLab Community to drive contributions. This is the only and best way to achieve adding support for all of the most common package manager formats in a timely manner.
  4. Improve the performance and reliability of builds by reducing reliance on external dependencies.

The details of how we'll achieve different elements of this can be found in the individual category pages below:

Package Registry

Every team needs a place to store their packages and dependencies. GitLab aims to provide a comprehensive solution, integrated into our single application, that supports package management for all commonly used languages and binary formats. This category is at the "viable" level of maturity.

DocumentationDirection

Container Registry

A secure and private registry for Docker images built-in to GitLab. Creating, pushing, and retrieving images works out of the box with GitLab CI/CD. This category is at the "viable" level of maturity.

DocumentationDirection

Helm Chart Registry

Kubernetes cluster integrations can take advantage of Helm charts to standardize their distribution and install processes. Supporting a built-in helm chart registry allows for better, self-managed container orchestration. This category is at the "minimal" level of maturity.

DocumentationDirection

Dependency Proxy

The GitLab Dependency Proxy can serve as an intermediary between your local developers and automation and the world of packages that need to be fetched from remote repositories. By adding a security and validation layer to a caching proxy, you can ensure reliability, accuracy, and auditability for the packages you depend on. This category is at the "viable" level of maturity.

DocumentationDirection

Dependency Firewall

GitLab ensures that the dependencies stored in your package registries conform to your corporate compliance guidelines. This means you can prevent your organization from using dependencies that are insecure or out of policy. This category is planned, but not yet available.

Direction

Jupyter Notebooks

Jupyter Notebooks are a common type of code used for data-science use cases. With GitLab you can store and version control those notebooks in the same way you store packages and application code. This category is at the "minimal" level of maturity.

DocumentationDirection

Git LFS

Git LFS (Large File Storage) is a Git extension, which reduces the impact of large files in your repository by downloading the relevant versions of them lazily. Specifically, large files are downloaded during the checkout process rather than during cloning or fetching. This category is at the "minimal" level of maturity.

DocumentationDirection

Release

The three year target for Release (high level roadmap; SMAU (Stage Monthly Active Users) dashboard) is:

The details of how we'll achieve different elements of this can be found in the individual category pages below:

Continuous Delivery

Deliver your changes to production with zero-touch software delivery; focus on building great software and allow GitLab CD to bring your release through your path to production for you. This category is at the "complete" level of maturity.

Learn moreDocumentationDirection

Pages

Use any static site generator to create websites that are easily managed and deployed by GitLab. This category is at the "complete" level of maturity.

Learn moreDocumentationDirection

Review Apps

Get a full production like environment for every merge request that updates on each commit. See code running and enable user acceptance testing before you merge. This category is at the "complete" level of maturity.

Learn moreDocumentationDirection

Incremental Rollout

Mitigate the risk of production deploys by deploying new production code to small subset of your fleet and then incrementally adding more. This category is planned, but not yet available.

DocumentationDirection

Feature Flags

Feature flags enable teams to achieve CD by letting them deploy dark features to production as smaller batches for controlled testing, separating feature delivery from customer launch, and removing risk from delivery. This category is at the "viable" level of maturity.

DocumentationDirection

Release Orchestration

Management and orchestration of releases-as-code built on intelligent notifications, scheduling of delivery and shared resources, blackout periods, relationships, parallelization, and sequencing, as well as support for integrating manual processes and interventions. This category is at the "viable" level of maturity.

DocumentationDirection

Release Evidence

Release Evidence includes features such as deploy-time security controls to ensure only trusted container images are deployed on Kubernetes Engine, and more broadly includes all the assurances and evidence collection that are necessary for you to trust the changes you're delivering. This category is at the "minimal" level of maturity.

DocumentationDirection

Secrets Management

Use HashiCorp Vault and GitLab to manage your GitLab secrets. This category is at the "minimal" level of maturity.

DocumentationDirection

Configure

While the market for the Configure stage has many strong incumbent players, it is splintered across many traditional IT management tools (Ansible, Chef, Puppet). There are emerging trends (i) showing a consolidation on containers (i) and specifically Kubernetes (i) for cloud-native application development. This will have the effect of stymying commercial players from locking in market share based on proprietary tools. So while there are strong players, the current market dynamics means there is upside for us.

You can read more about the Configure stage plan on the Configure Direction page.

The Configure stage is made up of several categories:

Auto DevOps

Commit your code and GitLab does the rest to build, test, deploy, and monitor automatically. Eliminate the complexities of getting going with automated software delivery by automatically setting up the pipeline and necessary integrations, freeing up your teams to focus on the culture part. This category is at the "viable" level of maturity.

Priority: medium • Learn moreDocumentationDirection

Kubernetes Management

Create and manage Kubernetes clusters with a few clicks. Install applications with a single click. This category is at the "viable" level of maturity.

Priority: high • Learn moreDocumentationDirection

ChatOps

Tight integrations with Slack and Mattermost make it easy to manage and automate software development and delivery right from your chat app. This category is at the "minimal" level of maturity.

Priority: low • DocumentationDirection

Runbooks

Runbooks are a collection of documented procedures that explain how to carry out a particular process, be it starting, stopping, debugging, or troubleshooting a particular system. Executable runbooks allow operators to execute pre-written code blocks or database queries against a given environment. This category is at the "minimal" level of maturity.

Priority: low • DocumentationDirection

Serverless

Run cloud-agnostic serverless workloads on Kubernetes, deployed via GitLab CI/CD. This category is at the "minimal" level of maturity.

Priority: low • Learn moreDocumentationDirection

Infrastructure as Code

Manage your infrastructure effectively to create, configure, and manage a complete software development environment. This category is at the "minimal" level of maturity.

Priority: high • DocumentationDirection

Chaos Engineering

This category is planned, but not yet available.
Priority: low • Direction

Cluster Cost Optimization

This category is planned, but not yet available.
Priority: low • Direction

Monitor

The market for the Monitor stage is aligned around key players New Relic, Splunk, ServiceNow and Datadog. Datadog, New Relic and Splunk are all headed towards integrated observability platforms based on collecting all available telemetry. ServiceNow (i) is considered a standard for help-desk and Incident Management workflows. Strong existing players with large sustained R&D investment will make it difficult for GitLab to compete head-to-head for Monitor stage market share, especially with traditional Operations and System Administration users.

You can read more about the Monitor stage plan on the Monitor Direction page.

The Monitor stage is made up of several categories:

Metrics

GitLab collects and displays performance metrics for deployed apps, leveraging Prometheus. Developers can determine the impact of a merge and keep an eye on their production systems, without leaving GitLab. This category is at the "viable" level of maturity.

Priority: high • DocumentationDirection

Alert Management

Consolidate all of your IT alerts in GitLab. Quickly triage and investigate problems by correlating alerts to relevant metrics, logs, traces, and errors. Elevate the critical ones to incidents for speedy resolution. This category is planned, but not yet available.

Priority: high • DocumentationDirection

Incident Management

Track incidents within GitLab, providing a consolidated location to understand the who, what, when, and where of the incident. Define service level objectives and error budgets, to achieve the desired balance of velocity and stability. This category is at the "viable" level of maturity.

Priority: high • DocumentationDirection

Logging

GitLab makes it easy to view the logs distributed across multiple pods and services using log aggregation with Elastic Stack. Once Elastic Stack is enabled, you can view your aggregated Kubernetes logs across multiple services and infrastructure, go back in time, conduct infinite scroll, and search through your application logs from within the GitLab UI itself. This category is at the "viable" level of maturity.

Priority: medium • DocumentationDirection

Tracing

Tracing provides insight into the performance and health of a deployed application, tracking each function or microservice which handles a given request. This makes it easy to understand the end-to-end flow of a request, regardless of whether you are using a monolithic or distributed system. This category is at the "minimal" level of maturity.

Priority: medium • DocumentationDirection

GitLab Self-Monitoring

Self-managed GitLab instances come out of the box with great observability tools, reducing the time and effort required to maintain a GitLab instance.

Priority: low • DocumentationDirection

Error Tracking

Error tracking allows developers to easily discover and view the errors that their application may be generating. By surfacing error information where the code is being developed, efficiency and awareness can be increased. This category is at the "viable" level of maturity.

Priority: low • DocumentationDirection

Digital Experience Management

Digital experience management includes both real user monitoring (passive) and synthetics monitoring (active) to allow developers to detect problems in end-to-end workflows and understand real-world performance as experienced by users. This category is planned, but not yet available.

Priority: medium • Direction

Status Page

Easily communicate the status of your services to users and customers. This category is planned, but not yet available.

Direction

What's Next

It's important to call out that the below plan can change any moment and should not be taken as a hard commitment, though we do try to keep things generally stable. In general, we follow the same prioritization guidelines as the product team at large. Issues will tend to flow from having no milestone, to being added to the backlog, to being added to this page and/or a specific milestone for delivery.

12.10 (2020-04-22)

Verify

Package

Release

Configure

Monitor

13.0 (2020-05-22)

Verify

Package

Release

Configure

Monitor

13.1 (2020-06-22)

Verify

Package

Release

Configure

Monitor