Everyone can contribute! Feel free to comment on our async AMA issue, email Jackie Porter, and propose an MR to this page!
The Verify Stage is responsible for executing on the market needs for continuous integration.
From our Continuous Integration use case:
When practicing Continuous Integration, teams collaborate on projects by using a shared repository to store, modify and track frequent changes to their codebase. Developers check in, or integrate, their code into the repository multiple times a day and rely on automated tests to run in the background. These automated tests verify the changes by checking for potential bugs and security vulnerabilities, as well as performance and code quality degradations. Running tests as early in the software development lifecycle as possible is advantageous in order to detect problems before they intensify.
The total addressable market (TAMkt) for DevOps tools delivering against the Verify stage is $2.3B in 2022 and is expected to grow to $3.9B by 2026 (13.95% CAGR) (i). The Verify Stage makes up 23% of the Ops market and represents a significant portion of GitLab's expanding addressable market.
The Verify Stage has continued to maintain a premium experience for individual and small teams of Software and DevOps Engineers with market share increasing each month as evidenced in our Verify product performance indicators (internal).
Delivering on the Enterprise use case is steadily increasing as evidenced in our Verify Paid user-product performance indicators (internal). To continue this growth, the Verify Stage needs to invest more in the scaling requirements for large organizations, deliver on a solution for building secure and compliant software, as well as prioritize the usability of our core CI capabilities.
Within the context of GitLab usage, there are three triggers for when CI is an appropriate next step:
The entry point for adoption is often through the .gitlab-ci.yml, or documentation and public forums.
Some prerequisites for adopting CI are as follows:
Combining GitLab's Mitigating Concerns with the Verify Stage perspective, the Continuous Integration vision has some significant strengths, weaknesses, opportunties, and threats to becoming the leading platform for building, testing, and optimizing code:
| STRENGTHS Internal resources to exploit |
WEAKNESSES Internal Concerns to mitigate |
OPPORTUNITIES External resources to exploit |
THREATS External Concerns to mitigate |
|---|---|---|---|
| We are one of the core adoption paths for our users at GitLab Developer first approach for experiences Meaningful insights from use of the DevOps platform |
Lack of usage data-informed product decisions Ineffectively managed Technical debt/bugs Over indexing to Enterprise Product Management |
Reduce friction between all functions of development in a single-platform Empower developers to manage operations, quality, and security by baking those activities into GitLab Embrace platform engineering by making it easy to manage CI practices at scale |
Competition is a concern as noted on our Mitigating Concerns page GitHub Circle CI JFrog HashiCorp Public cloud providers New market entrants |
As organizations migrate to a cloud-first strategy, Continuous Integration must work to adapt to any changing needs in scale, performance, and usability. The Verify Stage must simultaneously support the trend toward microservices architecture and infrastructure as code, while balancing the needs of monorepos. In response to the rise in supply chain attacks, there is an ever-increasing pace of government-issued directives, standards, and regulations focused on the security and integrity of the software supply chain. This means we must add features and capabilities that enable customers to efficiently meet the most stringent secure CI/CD and software chains of custody requirements. In order to adequately deliver on these expectations, the core competencies Continuous Integration must meet for Enterpises are as follows: build and test automation, pipeline configuration management, visibility into CI performance, and built-in compliance with security.
Our top competitors for the Verify Stage are GitHub Actions, and Jenkins. Secondarily, there are emerging competitors we are watching carefully such as CircleCI, Harness.io, TeamCity, Drone, and JFrog.
Our mission for GitLab Continuous Integration is to empower all users to easily contribute to the automated building, testing, and optimization of code across teams, organizations, and the Open Source Community.
From this mission, the GitLab Continuous Integration three-year vision is to become the leading platform for Software Engineers, DevOps Engineers, and Development Team leads for automatically building, testing, as well as optimizing code.
We will execute against this vision by:
.gitlab-ci.yml files.Some of the core JTBDs for our three year vision and strategies are as follows:
To define our top focuses and initiatives, the Verify Stage needs to have a concerted perspective on what GitLab will offer for the Continuous Integration use case. We are targeting the Ops Section Direction personas and will support these users with our Continuous Integration mission, vision, and one-year direction.
GitLab CI/CD unlocks the DevSecOps workflow. A key focus for the Verify Stage is supporting the automation of secure workflows in GitLab while delivering ease of use across GitLab CI/CD. Our goal is to be the best-in-class CI/CD platform of choice. To support this goal, we are investing in the following areas next year:
World-class DevSecOps experience
Advanced Security & Compliance
For a view of all the issues we have planned by quarter in 2024, check out our Verify Roadmap Issue Board.
There are important things we won't work on to focus on our one year plan.
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 more • Documentation • Direction
Category containing features associated with edit/compose your .gitlab-ci.yml.
Learn more • Documentation • Direction
Manage secrets and protect sensitive data to enable GitLab, or a component built within GitLab to connect to other systems. This category is at the "minimal" level of maturity.
GitLab Runner is the execution agent that is used to run your CI jobs and send the results back to GitLab.
GitLab hosted Runners for GitLab CI on SaaS
GitLab Runner fleet management at enterprise scale
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.
Keep build artifacts under control and actionable.
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.
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 more • Documentation • Direction
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 compute 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. For customers who self-manage a Runner Fleet, ensuring the security and compliance of the Runner execution environment is critical. Features such as the auto-removal of inactive runners and providing reporting and automation to manage outdated runner versions are just a few examples of features coming in Ultimate aimed at simplifying Runner operations and maintenance. To secure the flows for HashiCorp Vault users, we would like to automatically mask any Vault secrets that are fetched by GitLab CI. To ensure better pipeline compliance we plan to provide you with the ability to enforce the presence of specific variables when validating pipeline configuration. Lastly, our core promise for the Ultimate tier is enabling users to effectively monitor and best use their 50,000 compute minutes by setting compute minutes limits on their projects.
You can see features that we are considering including in this tier in this issue search.