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.
In FY22, we have committed to SaaS First. In the Verify Stage, this means prioritizing the scale of Continuous Integration and ensuring our users on GitLab.com are leveraging a reliable and available service. We are focused on a goal of 20M builds per day as it represents not only a target to drive our future architecture, but a volume that we expect to achieve within several quarters.
Currently, we are staffing this Category with 10% of the Verify output, or equivalent to ~3 engineers in Verify. After we establish the load testing effort, we will evaluate if additional headcount will be required to support this effort.
We are expecting to on-ramp additional headcount in FY22-Q3 per product#2178, raising the percentage to ~24% of the Verify headcount.
For specific information and features related to authoring/defining pipelines, check out Pipeline Authoring. You may also be looking for one of the following related product direction pages: GitLab Runner.
To begin working towards our goal, we will focus on the challenges section outlines in the Next CI/CD scale target: 20M builds per day by 2024 blueprint. These challenges revolve around various known issues with the ci_builds table. Challenges are listed below with related epics or issues capturing the work to be done. They are listed in priority order.
| Challenge | Related Epics & Issues | |
|---|---|---|
| 1 | We are running out of the capacity to store primary keys | gitlab#325618 - Complete |
| 2 | Queuing mechanisms are using the large table | gitlab!5909 - 14.2 |
| 3 | Moving big amounts of data is challenging | gitlab!6009 - 14.3 |
| 4 | The table is too large | gitlab#328603 - 14.3 |
| 5 | Development velocity is negatively affected | TBD |
| 6 | Create the capability to load testing the GitLab CI system* | gitlab#328736 |
As the new queuing mechanism rolls out, performance changes will be visible in the Duration of the builds queue retrieval using the big query SQL graph in Prometheus.
Our top vision items we have defined include:
