The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
The CI section is responsible for many of the experiences in GitLab after a developer commits changes to a project (source code repository). The DRI for this page is Jackie Porter, Director of Product and I welcome contributions - please open a merge request or send me an email.
Our mission for the CI Section is to empower all users to easily contribute to the automated building, testing, and optimization of code for GitLab customers and the Open Source Community.
Our vision is that in the next five years, GitLab CI/CD is the brand synonymous with CI/CD and recognized as the industry standard.
We are going to accomplish this by making the process of configuring, managing, and tuning CI/CD pipelines as frictionless as possible.
The CI Section is comprised of two stages: Verify and Package. For a deeper view of the direction of each specific stage please visit the respective Direction Pages linked below:
Inherited from GitLab's company mission, the CI section aims to support universal contribution from everyone in the software build and packaging processes. To accomplish this target, focusing on reducing complexity in the developer and platform operator workflow by prioritizing simplicity in our design, building with flexibility in mind for the enterprise workflow, and becoming an ecosystem for CI tools by thoughtfully integrating with other applications are the foundation for the strategy.
In addition to enabling developers with CI capabilities, we will also focus on supporting platform engineers with best-in-class tools for managing code, artifacts, and costs.
Organizations need a solution to effectively manage two sides of the software cost picture: developer cost and compute cost. There is a high demand for a single source to view and optimize builds and infrastructure internal research.
As we look into the future of build and package, migration and use case support will be a core focus. Journeys away from current tools are challenging. Our goal is to give you tools that can help make it easy to consolidate on GitLab so that you can save money on licensing costs and improve user experience.
With a win/win scenario in mind, the three year outcomes we would want to support as a section are as follows:
In three years the CI market will:
The CI Section is contributing actively to our Yearly Themes. In FY25, we plan to execute on:
The total addressable market (TAMkt) for DevOps tools delivering against the Verify stage is $3.4B in 2024 and is expected to grow to $3.9B by 2026 (13.95% CAGR) and the Package stage is $1.39B in 2024 with growth to $2B in 2026 (18.30% CAGR) (i). The Verify and Package Stages combined represents a significant portion of GitLab's expanding addressable market (23% of 2024 TAMkt).
The CI Section has continued to maintain a superior 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) and Package Product performance indicators(internal).
Delivering on the enterprise use case is steadily increasing as evidenced in our Verify Paid user-product performance indicators (internal) and Package Paid user product performance indicators (internal).
To continue this growth, the CI Section needs to invest more in the scaling requirements for large organizations, deliver on solutions for helping organizations build secure and compliant software, as well as prioritize the usability of our core CI and Packaging capabilities.
Within the context of GitLab usage, there are three triggers for when CI/Packaging 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:
The CI 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 for leaders in markets GitHub Circle CI JFrog HashiCorp Public cloud providers New market entrants |
As organizations migrate to a cloud-first strategy, the CI Section must work to adapt to changing needs in scale, performance, and usability. The Verify and Package Stages 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. To adequately deliver on these expectations of the Enterprise market, the Verify and Package Stages must practice the following principles: security on-by-default, developer productivity, and cost effectiveness.
In FY25, we will achieve this by adding support for:
Our top competitors for the CI Section are GitHub and Jfrog. Secondarily, there are emerging competitors we are watching carefully such as JetBrains and Harness.io. In the install base, more specific to Verify Stage, we have strong users of Jenkins/Cloudbees, and for Package stage there is some usage of Nexus for Artifact management.
See the Package competitor page
Some of the core JTBDs for our three year vision and strategies are as follows:
We identify the personas the CI 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.
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.
There are several key cross-functional investments that will further our competitive position, security posture, and customer experience. The efforts are outlined below:
| Area | Teams | Target Investment Year |
|---|---|---|
| CI Steps | Pipeline Authoring; Runner Core | FY24 |
| CI/CD Migration Tooling | Pipeline Execution; Pipeline Authoring | Not Yet Defined |
| CI/CD Visibility | Pipeline Execution; Observability; Runner Fleet | FY25 |
| Observability and AI Optimization | Pipeline Execution; Observability; Runner Fleet | FY26 |
| Caching | Pipeline Authoring; Runner Core | FY25 |
| CI job queueing | Pipeline Execution; Runner Core; Runner SaaS? | FY26 |
| Runner priority - routing jobs to a specific runner | Pipeline Execution; Runner Core; Runner SaaS? | FY25 |
| CI log rendering user experience | Pipeline Execution; Pipeline Authoring; Runner Core | FY25 |
| Events | Pipeline Execution; Package; Runner SaaS | FY25 |
| Runner Next (re-architecture of Runner Core) | Runner Core | FY24-FY25 |
| GCP/GitLab Console Integration | Runner Core; Package | FY24-FY25 |