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

Section Direction - Ops

Ops Section Overview


The Ops Section stages are at the forefront of GitLab's single DevOps platform vision of enabling everyone to contribute. The stages represent half of GitLab's Total Addressable Market expansion during the next five years and the markets where we have some of the lowest current penetration. As a result the opportunity and impact from R&D investment in these stages are the highest in the company.

User growth in Ops Section stages improves Stages per Organization beyond typical SCM customers - providing the value of a single DevOps platform to our customers. Adding new types of users in turn increases unique active users, while adding paid tier features increases Average Revenue Per User (ARPU) and broad adoption across users in our customers' organizations increases net retention. All of these are critical drivers of our GitLab's business performance.

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



The Ops Section is comprised of five stages: Verify, Package, Release, Configure, and Monitor. The Release and Configure stages are grouped under the Deployment section. For a deeper view of the direction of each specific stage please visit the the respective Direction Pages linked below:

Market analysts (internal) often describe these stages as automated software quality (ASQ, partially correlated with Verify, Package and Release), IT automation and configuration management (ITACM, correlated with Configure), and IT operations management (ITOM, partially correlated with Monitor). The section also covers CI/CD (Verify/Release), IT Infrastructure Monitoring/APM (Monitor), CDRA (Release), Infrastructure Configuration (Configure) and Package and Binary Management (Package) analyst categories.

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 value stream delivery platform 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 early support for platform operations and SRE teams who provide Pipelines, Infrastructure and alert response tools to development teams, and ambitious plans to support traditional operators in the future.


Ops Section Market by Stage

The total addressable market (TAMkt) for DevOps tools targeting these stages was $5.2B in 2019 and is expected to grow to $10.7B by 2024 (18.8% CAGR) (internal). This analysis is considered conservative as it focuses only on developers and doesn't include additional potential users. This is a deep profit pool and represents a significant portion of GitLab's expanding addressable market. As organizations further adopt DevOps, developer focused ops tools account for a larger share of market. This market has traditionally targeted IT Architects, System Admins and Operators where large hardware budgets enabled expensive IT tools to flourish.

The market is well established (internal), but the participants are evolving rapidly. Existing leaders in single stages of the DevOps lifecycle are expanding to build value stream delivery platforms (internal), what GitLab calls complete DevOps platforms delivered as a single application. These existing players are doing so via acquisition and product development. The leaders run the gamut from GitHub with their strong position in the SCM market and their growing capabilities to compete in CI/CD, to Delivery focused tools such as Harness and JFrog, to DataDog and New Relic with their strong positions in APM. All are pivoting to pursue the value stream delivery platform market.

Expanding market players such as GitHub are taking market share from traditional participants like CloudBees in the Verify stage. In the Package stage, JFrog is looking to expand their leadership position in artifact repositories into other part of value stream delivery. In the Release stage, Harness has capabilities which span Verify and Release as well as have taken an integrative approach covering the Configure and Monitor stages. Both Harness and tools like it are 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 monitoring platform. IBM (+RedHat), HashiCorp, Puppet, and Chef share 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 growing, especially in the Verify, Package andRelease stages. For the Configure stage, our advanced Kubernetes and Terraform integrations position as as a forward-thinking market entrant. For Monitor, our unique perspective as a single and complete DevOps application positions us for growth.

You can see how users currently use our various stages in our Ops Section product performance indicators (internal) and Ops Section Usage Dashboard (internal).

We are continually investing in R&D in all Ops Section stages. The maturity of each stage and category can be found in our maturity page. Our investment in the Ops section stages (internal) is critical to both enabling enterprise users to continue on their DevOps maturity journey and completing our complete DevOps platform vision. Driving adoption across multiple Ops stages enables early adopters to recognize the benefit of a single application.


Ops Section Challenges

Our current challenges span a wide range, first and foremost, market challenges (in priority order):

  1. GitLab created a new market for DevOps platforms delivered as a single application. 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 acquisition (JFrog, CollabNet/VersionOne/XebiaLabs). By 2023, the number of companies switching to VSDPs is expected to quadruple (internal).
  2. Beyond the key players, there is also rapid innovation. This makes for a market where there is proliferation of new technology concurrent to 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.
  3. 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 (such as Platform Engineers) and tasks, market entrants' products result in a checklist of modules that lack a cohesive experience for users.
  4. 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 provider's infrastructure. There is a possibility that these provider-centric ecosystems present organizations with a choice of investing in a best-of-breed platform with a small subset of projects or a just sufficient enough platform used by all.

Outside of market challenges we have some internal ones as well:


Given these challenges, here are some key opportunities we must take advantage of (in priority order):

  1. Cross-Use Case Workflows: As a single DevOps platform, a single user may action and span multiple use cases in there day experience with GitLab. Our ability to drive awareness of each additional use case while users are doing their job will fuel the Ops Section stage adoption growth. We have an opportunity to prompt users to explore new functionality within their existing workflow. An example might be prompting users without CI/CD on projects that contain Terraform code to utilize our Terraform MR review widget. Doing so will organically inspire more adoption and usage of cross-platform tools. This usage will result in an improvement of productivity for our users or some other ROI, supporting the expansion of seats to include more users within an organization's instance.
  2. DevOps Adoption Pains: For many organizations their DevOps journey is currently stalled as they attempt to adopt continuous delivery in an effort to increase their deployment frequency. GitLab's common method for defining CI and CD workflows allows organizations to use the same tools their teams love for CI when overcoming this new challenge. Even elite DevOps organizations struggle to bring measurement of their entire software delivery performance into one tool. GitLab's combination of Create, Verify, Release and Monitor allow our users to measure all four aspects of their delivery performance. DevOps transformations are also hampered by a lack of IT operations skills (internal). Most organizations have taken to creating infrastructure platform teams to minimize the amount of operations expertise required by DevOps team members (internal). Those teams' traditional operations tools are not integrated within the development team's workflow, and force an unneeded tradeoff between reliability and speed. This tradeoff results in increased down-time and problems with recovering from disaster - or slowed business agility. Value Stream Delivery Platforms like GitLab can move a team from reactive to proactive reliability without sacrificing development velocity (internal).
  3. Increasing Developer buying power: In the move to DevOps, tools focused on enabling developers will garner increased share of wallet. 71% of organizations (internal) will achieve full DevOps adoption on some projects within a year. 35% of DevOps implementations include Monitor stage capabilities, 30% include Configure stage ones (internal). This increasing buyer power is driven by the cultural and organizational changes (often called Digital Transformation Initiatives) needed for DevOps to deliver software faster. This also applies to traditional IT teams who will, by 2024 see 30% of their focus move from IT ops to continuous engineering via role shifts like moving from system admin roles to SRE roles.
  4. Market Recognition: The IT market has recognized the value of GitLab's core proposition, a complete DevOps platform delivered as a single application. We know because single-function companies are consolidating, and analysts have created a new category - VSDP - to describe that proposition. One key value driver for this market is the shifting-left of traditional Ops tasks ensuring reliability doesn't have to come at the expense of speed.
  5. IaC and GitOps are strong first steps towards AIOps: AIOps strives to provide self-learning, self-healing IT operations massively impacting IT operations professionals and their tools. However, it is early in the hype cycle (internal) and being successful will depend on DevOps teams first defining their infrastructure, operations, and observability as code. IT Operations teams are first adopting automation and programmable infrastructure (Automated Ops) in order to keep up with developer velocity. Experience with developer tools like source control and CI/CD tooling are becoming requirements for operations teams, often replacing inefficient CMDB tools in the process. GitLab's roots in SCM and CI and the entire GitOps, Infrastructure as Code, and Observability as Code movements will help us attract and add value for Ops personas and set us up for future AIOps success.
  6. Continuing commoditization of tooling: Well funded technology companies (Google, Netflix, Lyft, Spotify etc.) that are focused on meeting scaling challenges have a history of releasing open source software that leap-frog vendor software. Examples include Kubernetes, Prometheus, and many of the foundational projects in CNCF. In the observability space, 70% of instrumentation is expected to be open-source by 2025. DevOps vendors have to continue to move up the value chain as previously specialized software gets commoditized. GitLab has the opportunity to mind the Developer Experience Gap and provide an easy to use and effective software development toolchain.

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 beyond application code to 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 (such as, developer buyer power, IT skills gaps, a move towards Kubernetes, and our roots in source-control and CI) by utilizing a dual-flywheel approach. This approach starts with attracting developers performing DevOps tooling and operations tasks to our Free/Core tier. As we build best of breed tools for them we will co-create to drive product improvements. This will generate revenue for higher product tiers and additional investment for supporting the modern development teams.

More specifically, we will achieve this by enabling easy-to-discover, working-by-default, workflows that support doing powerful, complex actions with a minimum 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 is available everywhere and to everyone, embedded naturally into their day-to-day workflow where it's relevant. For example:

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

Ops Section TAM Expansion

The Ops Section stages represent over 50% of GitLab's future TAM expansion. In three years the Ops market will:


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's path to production as well as the performance of their production application itself. We also want to ensure they have the tools to contribute to feature development and the complete end-user experience of their application.

Our Ops Section themes are additive to our overall Product Principles and Yearly Themes, namely:

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 Continuous Integration and Verify product direction. 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 were 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. We produce best practices to ensure your pipeline is efficient. 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 pay on every job invocation setting up the environment, fetching dependencies, and so on.

Progressive Delivery and Deployment

Progressive Delivery is a set of emerging Continuous Delivery (CD) best practices, oriented around implementing safety and automation in incrementally deliverying (sometimes without deployment) software changes over time. 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.

Ops as Code

There have been four major trends impacting operations; they are all essential to enabling Developer style workflows for operational tasks by defining those activities as code (or data). They are Pipelines as Code, Infrastructure as Code (IAC), Observability as Code (OAC) and Policy as Code. At GitLab, our roots in SCM make us especially well suited for supporting these trends.

Pipelines as Code

GitLab CI/CD is based on pipelines as code principles and a key competitive advantage against other tools that require manual configuration of pipelines. Standardizing on common CI/CD pipeline tools has been proven to increase business results. The value of defining pipelines as code (i) is evident:

GitLab will continue to lean into our pipelines as code capabilities by adding support for releases, advanced deployments and complex builds directly in your .gitlab-ci.yml files. We'll also add more support for sharing common pipeline code across groups to create a consistent CI/CD platform within your organization.

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.

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.

Policy as Code

Policy 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.

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 utilize modern operations practices, avoiding alert fatigue by detecting real user events enabling them to resolve like a pro. Not just on its features, but on the overall experience delivered to your users. Rapidly.

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 DevSecOps teams with these smart additions.

Performance Indicators

The performance of the Ops section is defined as the total adoption of its stages as measured by the Ops Section Total Stages Monthly Active Users (internal)) (Ops Section CMAU). Ops Section TMAU is a sum of all SMAUs across the five stages in the Ops Section (Verify, Package, Release, Configure & Monitor).

To increase the Ops Section TMAU, the product groups are focused on driving their stage adoption. We are especially focused on increasing adoption of the Verify and Release stages by driving CI usage from existing SCM users and driving CD usage from existing CI users. This will activate users into Ops Section TMAU and enable them to continue to adopt other Ops section stages as described on Ops section adoption journey (see also the product-wide adoption journey):

graph LR %% Define Styling classDef OpsStage fill:#11f,color:#fff classDef OtherStage fill:#ddd,color:#888 %%% Define Stages P[Plan]:::OtherStage C[Create]:::OtherStage V[Verify]:::OpsStage Pa[Package]:::OpsStage R[Release]:::OpsStage Co[Configure]:::OpsStage M[Monitor]:::OpsStage S[Secure]:::OtherStage D[Protect]:::OtherStage %% Define Connections C -.- P P -.-> M V -.- S C ==> V V ==> R V ==> Pa V ==> Co R ==> M R -.- Co Co -.- D Co ==> M M -.- D subgraph "Legend" Legend1[Ops Stage]:::OpsStage == Critical Path==> Legend2[Other Stage]:::OtherStage Legend1 -. Additional Path .-> Legend2 end

The majority of our Ops section product groups are focused on driving adoption first, and then monetization within their category scope. Some groups are well placed to focus on monetization right away by adding tier value for buyer personas (e.g. development manager, director) on top of existing stages which already have heavy usage.

See more details about our Product Performance Indicators in our Ops Section Product Performance Indicators page.

Critical Jobs to Be Done

GitLab will focus on the jobs to be done (JTBD) found in the workflows identified across all of our stages. Today we've identified those critical JTBD in the Package, Configure and Monitor stages.

The most critical are:

Who is it for?

We identify the personas the Ops section features are built for. In order to be transparent about personas we support today and personas we aim to support in the future we use the following categorization of personas listed in priority order.


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

  1. 🟩 Sasha - Software Developer
  2. 🟩 Devon - DevOps Engineer
  3. 🟨 Priyanka - Platform Engineer
  4. 🟨 Allison - Application Ops
  5. 🟨 Simone - Software Engineer in Test
  6. 🟨 Delaney - Development Team Lead
  7. 🟨 Rachel - Release Manager
  8. ⬜️ Ops Teams
  9. ⬜️ 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. 🟩 Priyanka - Platform Engineer
  2. 🟩 Sasha - Software Developer
  3. 🟩 Devon - DevOps Engineer
  4. 🟩 Allison - Application Ops
  5. 🟩 Simone - Software Engineer in Test
  6. 🟩 Delaney - Development Team Lead
  7. 🟩 Rachel - Release Manager
  8. 🟨 Ops Teams
  9. ⬜️ Central IT / System Admins

One Year Plans

Each Stage maintains Direction content that contains upcoming plans.

Ops Section Plan

Our plan is quite simple. We see a common progression in all of our GitLab stages and categories. That progression is:

  1. Create MVCs which showcase the possibility of new categories in a single-application
  2. Leverage the high rate of learning provided by dogfooding to achieve viability
  3. Shift focus to awareness and acquisition of viable capabilities by increasing SMAU & GMAU
  4. Begin building completeness and tier value as a result of increased SMAU

As a result our performance indicators and tier strategies are aligned to the maturity of each stage.

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

What's Next

Each Product Group in the Ops Section maintains a version of their What's Next.

Acquisition Plan

GitLab pursues acquisitions which will help accelerate our product roadmap. There are a few categories across the Ops Section stages which have a higher appetite for acquisition. We look for one of two things:

  1. Planned future category maturity increments where the jump from minimal or viable to complete or lovable would necessitate significant R&D investment and an acquisition would accelerate that maturity significantly.
  2. Filling gaps in our themes that span our current categories. As a result our top priorities are:

Roadmap Acceleration

  1. Observability - We plan to pursue adding on-by-default observability capabilities to GitLab via our SEG. Tools that provide similar capabilities faster than our current investment plan will deliver are considered a top priority.
  2. CI Testing - Tools that immediately increase our capability in a Verify:Testing group category AND provide a framework for an over-time and cross-project view of testing results.
  3. Build and Pipeline Optimization - Tools that enable pipeline efficiency and increase pipeline speed to save developers time
  4. Infrastructure Cost Optimization - Tools that provide insights into cost implications (especially in MR workflows), alerting and dashboarding enabling users to optimize their infrastructure utilization.

Longer horizon acquisition options

Some acquisition options in the Ops Section aren't immediate requirements for our single-devops platform. Instead they represent our vision for an expanded DevOps platform.

  1. In line with our theme of Smarter Feedback Loops we are also considering Tools that enable the continuous improvement of applications via efficient feedback loops from production to the Plan and Create stages, including product product analytics, user forums, suggestion mechanisms, and real-user monitoring. These are distinct from Marketing focused tools that are meant to provide feedback on campaigns and content.
  2. In line with our theme of Operations as Code we are also considering tools and software that improve the ability to define platforms (including observability systems) and repeatedly deploy them alongside application code.
  3. We are considering tools that enable Operations for All by helping developers quickly define and utilize complex infrastructure setups. These include internal developer platforms, service catalogs, and IaC interfaces.

Future Investment

In the Ops Section we must diligently prioritize and sequence our investments in a very expansive market from CI adoption from existing SCM users to MVCs in Monitor and Log Management markets.

+10% Investment Priorities

As a result we maintain a list of our +10% investment priorities to ensure we are balancing capturing short-term and long-term markets. The following are our current +10% investment priorities:

  1. Runner Cloud
  2. Scanner Group
  3. Shift Left Testing

You can see a full list of investment cases using this issue search.

Strategy Development

The Ops Section includes many market categories each with their own significant TAMs. We prioritize evaluating and developing a strategy for pursuing each of these markets via the following priority list:

  1. Monitor & Log Management - This is a large market that we must compete in over time but that we aren't currently prioritizing any investment towards.
  2. A/B Testing and Experimentation Framework
  3. Product Analytics & Feedback - We have an internal team pursuing this effort but only as part of a dogfooding initiative.

Useful Resources

Below are some additional resources to learn more about Ops:

Current Validation Track Initiatives

Check out the following links for current problem validation cycles and solution validation cycles for the stages in the Ops section. You can also see the recently completed problem and solution validation issues in our issue tracker.

You can also find Opportunity Canvas artifacts for Ops Section Validation Track activities in our:

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.


Akin to other Ops Stages, Verify is propelled to drive forward our north star metric of SMAU, which is unique users triggering pipelines.

With millions of developers using GitLab CI globally, we want organizations to ship their code as fast as possible without compromising quality, security, ease of use or the integrity of their software. We believe that we can empower users and enterprises to employ the most advanced best practices for Continuous Integration for use in application development across Data, ML/AI, Infrastructure as Code, as well as Operations Workflows.

In the in the back half of FY22, we are prioritizing the folllowing to materialize this vision:

  1. Delivering on Operations for All by expanding our offerings to support more time of platforms and enabling more use cases across GitLab. Top of the list is Runner support for macOS via gitlab#284838 and Windows Shared Runners in gitlab#300476. Use case expansion includes prioritizing efforts around compliance which includes better visibility into Compliance Pipelines via gitlab#334486 as well as supporting Protected Runners in gitlab&6058.
  2. We are also making a concerted effort on Speedy, reliable pipelines by prioritizing usability fixes across Pipeline Execution, Testing, and Pipeline Authoring. These fixes will enable a more seamless use of features like Merge Trains, Job Logs, and Variables.
  3. Investing in Smart Feedback Loops are top of mind for the Verify Stage. We are looking to empower users and decision makers with better data about Project Code Quality in gitlab&5430 and CI minute usage in gitlab&5653.
  4. More broadly across GitLab we are investing in SaaS First. As a result, a top investment in Verify will be scheduling and delivering fixes related to infradev to support the availability and performance of

We have also been working on 3-year visions for groups within Verify, such as Continuous Integration's mocks which can be found in gitlab&4793 and Pipeline Authoring's mocks located in gitlab&4534.

Verify Investment Cases

In the Verify Stage, we have several investment cases highlighted as top priorities for future investment in the Ops Section. Additionally, there are investment cases beyond the ones identified stack ranked by potential return on investment as indicated by priority below:

  1. Priority 1 Investment Cases
  2. Priority 2 Investment Cases
  3. Priority 3 Investment Cases

Verify Stage Categories

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 "complete" level of maturity.

Learn moreDocumentationDirection

Continuous Integration Scaling (CI Scaling)

Watch us reach 20M builds per day on


Pipeline Authoring

Category containing features associated with editing/authoring your .gitlab-ci.yml.

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.


Jenkins Importer

The Jenkins Importer helps unblock teams from migrating to GitLab CI. This category is at the "viable" level of maturity.


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 "viable" level of maturity.


Build Artifacts

Keep build artifacts under control and actionable.


Performance Testing

Be confident in the performance of your changes by ensuring that they are validated against real world scenarios. This category is at the "minimal" level of maturity.


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.


Accessibility Testing

Beyond being a compliance requirement in many cases, accessibility testing is the right thing to do. This category is at the "viable" level of maturity.


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.


Review Apps

Get a fully functional pre-production environment for every merge request that updates on each commit. See code running, and enable user acceptance testing and automated smoke tests before you merge. This category is at the "complete" level of maturity.

Priority: low • Learn moreDocumentationDirection


The Verify group is at the entrypoint to the funnel in our user adoption journey, so our features are an critical enabler for users seeking a complete DevOps platform. While we do try to drive adoption in order to support multi-stage growth at least partially through features at the free tier, it's also important for us that we have features at the paid tiers. For our group, these will typically be cross-department and cross-company views related to CI templates, quality and pipelines. See below for the how we are thinking about each of the tiers, and the kinds of features that will be included.


The foundation of the Free strategy for Verify is that enhancements to baseline CI YAML features will be available in this tier by default. The rationale for this approach is that we want to preserve a consistent experience. Users must always be able to use the same .gitlab-ci.yml in all tiers.

Beyond this, features that drive broad adoption and help with onboarding (including generally making it easier to get started with GitLab CI) are also good candidates for inclusion in this tier. Providing solutions to simplify the deployment and management of Runners at scale for self-managed is also critical for all tiers of users.


The default paid tier for enterprises, Premium will cater to directors operating a medium to large instance. We will focus on features that solve for typical entry-level enterprise needs: reporting and analytics supporting Ops Insights, operational efficiency driving effective project management, and supporting visibility in consumption related to 10,000 CI/CD minutes per month medium to large organizations.

You can see features that we are considering including in this tier in this issue search.


Using GitLab CI across hundreds or thousands of projects in large enterprises means a greater need for portfolio management and consistency of experience in development practices. This is accomplished by making templates discoverable via gitlab#320698 and a consistent authoring experience such as in these issues. Additionally, the larger the organization the greater the need for regulation and compliance which is where features like Protected Runners captured in gitlab&6058 or better integrations with Compliance Pipelines become especially attractive. Lastly, our core promise for Ultimate tier is enabling users to effectively monitor and best use their 50,000 CI/CD minutes in visualizations such as a energy consumption dashboard via gitlab#325852.

You can see features that we are considering including in this tier in this issue search.


The goal of the Package Group is to build a product, that within three years, is our customer's single source of truth for storing and distributing images and packages.

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

The Package stage is made up of several categories:

Package Stage Categories

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.


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.


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 "viable" level of maturity.


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.


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.



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.



When considering which tier new feature belongs, we use two a buyer-based and thematic model.

The former helps us to consider who the feature is for and the latter to consider how the feature fits within the broader GitLab application. If you are interested, consider reading more about the GitLab pricing strategy.

The below details how we are thinking about each of the tiers and the kinds of features that will be included.


The Free version of the product includes the ability to publish, download, and share dependencies using your GitLab credentials.

We'll focus on usability, reliability, and seamless integrations with GitLab continuous integration and delivery. We will ensure that our product is easy and rewarding to contribute to. We will continue to rely on the GitLab Community to help define and refine our product offering. This includes adding support for new package manager formats.

Roadmap features targeted for tier:


From a buyer perspective, Premium features will be focused on team(s) usage, with the purchasing decision led by one or more Directors. The features in this tier will generally align with the themes

  1. Faster code reviews
  2. Ops insights

Faster code reviews mean that you can deploy and iterate faster. By using GitLab for your project's dependencies, you can reduce the amount of time it takes to verify and validate that a package or container image has been built properly.

But we know that you likely rely on dependencies from a number of remote repositories. That's why we'll be focused on adding support for remote and virtual registries and a generic proxy for container registries. This set of features will ensure that your team can view and manage all of their dependencies in one central location, making code reviews easier and more efficient.

Once your team(s) are using GitLab to manage dependencies, it's important to understand how those dependencies are being used at your organization. That's where the theme of Ops insights comes in. On the roadmap, we have a feature planned to help you measure and display the number of downloads for dependencies.


Directed toward an executive likely buyer, we will focus our efforts here on serving the needs of our larger, enterprise customers. This means introducing features that align with the themes:

  1. Advanced security testing
  2. Compliance

This means that the planned dependency firewall category will fall under this tier.


For details about the Release Stage Direction please check out that handbook page.

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

Release Stage Categories

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.

Priority: medium • Learn moreDocumentationDirection


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.

Priority: low • Learn moreDocumentationDirection

Advanced Deployments

Mitigate the risk of production deploys by deploying new production code to a small subset of your fleet and then incrementally adding more. This category is at the "viable" level of maturity.

Priority: low • 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.

Priority: medium • DocumentationDirection

Release Evidence

Release Evidence 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.


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.

Priority: high • DocumentationDirection

Environment Management

Enable organizations to operate and manage multiple environments directly from GitLab. Environments are encapsulated in GitLab as a target system with associated configurations. By facilitating access control, visualizing deployments and deployment history across teams and projects, adding the ability to query environments, and ensuring that environment's configurations are traceable, platform engineers can enact stronger controls and avoid costly mistakes in deployments. This category is at the "minimal" level of maturity.

Priority: high • DocumentationDirection


To support our goals in 2020 and our 3-year strategy, Release will continue enriching the free features while adding tier value. In our adoption journey, the Release features are typically consumed after continuous integration and source code management, so we will work to expand the independent use of continuous delivery features. While investing in the reduction of barrier to entry into Release we will spend time meeting the needs of the Enterprise by adding visibility into the benefits of using GitLab end-to-end.


Release will continue investing in the free solution to reduce the barrier of entry into Release as both as part of additional Gitlab adoption from existing CI users and as an independent solution without needing to use CI or SCM. We will focus on simplifying the process of managing releases and deploying progressively while empowering developers to release independently using GitLab. Roadmap features targeted for this tier include:


As the default paid tier for enterprises, Premium will cater to directors operating a medium to large instance. We'll direct features that solve for typical entry-level enterprise needs: reporting and analytics, operational efficiency, deployment automation, security and compliance, and other needs that are must-haves for medium to large organizations. While this type of organization should be able to get started in GitLab at lower tiers, they won't be able to thrive at scale. Roadmap features targeted for this tier include:


This tier is directed toward an executive likely buyer. Release groups will direct capabilities into Ultimate which serve the organizational needs of a complex enterprise operating a large GitLab instance. We'll focus on features which will help drive compliance into the continuous delivery workflow and shift security left into the development pipelines. Roadmap features targeted for this tier include:


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:

Configure Stage 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

Connect Kubernetes clusters to GitLab for deployments and insights. This category is at the "viable" level of maturity.

Priority: high • Learn moreDocumentationDirection

Delivery Management

Enable platform engineers to use GitLab as their deployment platform: platform engineers can define common DevOps practices, streamline compliance, and share common patterns to enable application development teams to be more efficient. This category is at the "minimal" level of maturity.

Priority: high • Direction

Secrets Management

Securely deploy with CI/CD Variables, Deploy Keys, Deploy Tokens, and HashiCorp Vault Integration. This category is at the "viable" level of maturity.



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

Infrastructure as Code

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

Priority: high • DocumentationDirection

Cluster Cost Management

Gain insights and recommendations about your cluster spending This category is at the "minimal" level of maturity.

Priority: low • DocumentationDirection




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 product analytics. 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:

Monitor Stage Categories


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


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 "minimal" level of maturity.

Priority: medium • 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

On-call Schedule Management

Track DevOps responsibilities within your team by creating rotating schedules for responders. This category is at the "minimal" level of maturity.

Priority: high • DocumentationDirection


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 "minimal" level of maturity.

Priority: medium • DocumentationDirection


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 "minimal" level of maturity.

Priority: medium • DocumentationDirection

Synthetic Monitoring

Proactively simulate, monitor, and report on success rates and executions for user actions and behavior pathways.

Priority: low • Direction

Product Analytics

This category is at the "minimal" level of maturity.
Priority: medium • Documentation


To support our goals in 2020 and our 3-year strategy, Monitor will continue enriching the free features while adding tier value focusing on Incident Management. While investing in the reduction of barriers to entry into Monitor, we will spend time meeting the needs of the Enterprise by adding visibility into the benefits of using GitLab end-to-end.


Monitor will continue investing in the free solution which enables users to set up foundational incident management workflows directly in GitLab. Features in this tier include:


As the default paid tier for enterprises, Premium will cater to directors operating a medium to large instance. We'll direct features that solve for typical entry-level enterprise needs: with alert integrations, incident issues native to GitLab, on-call schedule management, escalation policies and runbooks. While this type of organization should be able to get started in GitLab at lower tiers, they won't be able to thrive at scale. Premium will offer features that enable directors to integrate their monitor tools. Features targeted for this tier include:


Monitor will direct capabilities into Ultimate which serve the organizational needs of a complex enterprise operating a large GitLab instance. Ultimate users will gain efficiency with all of their different tools working well together within and as a part of GitLab. Roadmap features targeted for this tier include:

What's Next

See what is coming across all of the DevOps stages in our Upcoming Releases page.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license