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.
Continuous Integration (CI) is an important part of any software development cycle, and defined as part of the Verify stage here at GitLab. As declared in our Ops Section direction, we recognize a key advantage of GitLab CI is that we can define pipelines as code, while making CI easy to use, reliable, and accurate in terms of its results. We are very proud that we are recognized as the leading CI/CD tool on the market, as well as a leader in the 2019 Q3 Cloud Native CI Wave, and it's important for us that we continue to innovate in this area and provide not just a "good enough" solution, but a speedy and reliable one.
Making it easy to run a pipeline is our first focus and this applies to both running a pipeline manually as well as triggering one automatically when submitting a code commit or a merge request. In addition, we want to provide data for examining your pipeline's performance, so that you can optimize CI configurations to make your pipelines run more efficiently.
For specific information and features related to authoring and pipelines, check out Pipeline Authoring. For work related to Pipeline Abuse Prevention, see the Category page.
You may also be looking for one of the following related product direction pages: GitLab Runner, Continuous Delivery, Release stage, or Jenkins Importer.
Check out our Ops Section Direction "Who's is it for?" for an in depth look at the our target personas across Ops. For Continuous Integration, our "What's Next & Why" are targeting the following personas, as ranked by priority for support:
As part of the FY24 Product Themes we plan to support the following areas.
As we think about Speedy, Reliable Pipelines an area we can control is the time it takes to create a pipeline. In FY24 we will focus on making this part of pipeline runtime faster to contribute to the next GitLab CI job performance benchmark.
We also think about how scale can impact performance of pipelines Now that we have delivered the Next CI/CD scale target: 20M builds per day by 2024 blueprint and related scope on queueing mechanisms via gitlab&5909, primary key capacity via gitlab#325618, and handling large amounts of data via gitlab&6009, and have delivered our CI/CD Time Decay blueprint, we are ready to begin Phase II of CI Scaling: partitioning data with the CI/CD Time Decay pattern.
The first track of effort will be focused on partitioning the active CI/CD tables via gitlab&5417 and the second track is to partition queuing tables via gitlab&7438.
This group uses an issue board and CI Scaling to identify the scope that is in workflow. The team is tracking progress of the partitioning work in the documentation.
The following epics are used to coordinate the phases of CI Partitioning:
GitLab lets users make use of various tokens that allow ability to deploy and access resources within projects (Deploy tokens and the CI_JOB_TOKEN for example). Even staying diligent these tokens could be leaked by users providing powerful capabilities to nefarious actors. To better protect users will will strive to detect and remediate GitLab provided tokens found in job logs. We are tracking this effort in the epic gitlab&8007.
The CI_JOB_TOKEN makes it intuitive to access the GitLab API from within jobs to enable advanced automation. To enhance the security of this short lived token we will let project maintainers set which projects can use the token to interact with their project with the next phase of the CI_JOB_TOKEN workflows epic. Our vision is for this workflow to be the default for all projects with the next major release.
Our current maturity is at "Complete" and the next maturity target is "Lovable" (see our definitions of maturity levels). We previously reached "Lovable" in 2017, after being listed a CI Leader. In order to maintain this lead while staying ahead of the changing DevOps landscape needs for stability, performance and quality we need to reestablish a strong foundation of the core elements for CI. As such, we are prioritizing bugs and user experience improvements, while continuing to design and validate features for future implementation that move our vision forward. The following investments will be key to moving our maturity forward in the next two quarters:
These investments will lay the ground work to deliver on the top vision items in 2022 (see Epic#4794) which involve features under these key areas:
Our strategy above to regain a category maturity of "Lovable" is two-fold - first, a renewed focus on strengthening the core features of CI that support running a pipeline; and second, deliver features that provides more users with the ability to run pipelines in a project. To execute with purpose on these plans means there are opportunities in the CI category that we will not be pursuing. While this is not an exhaustive list, below are popular features/topics representing groups of issues that are currently not prioritized on our roadmap.
The majority of CI market conversation is between us, Jenkins, and GitHub Actions at this point. An example of this placement is from Jet Brain's 5th annual Developer Ecosystem Survey which has placed GitLab as #2 CI solution for enterprises. Atlassian has built BitBucket Pipelines, a more modernized version of Bamboo, which is still in the early stages. Microsoft is maintaining (at least for now) Azure DevOps at the same time as GitHub Actions but for personal usage GitHub Actions is gaining traction among developers. CodeFresh and CircleCI have both released container-based plugin model, similar to GitHub Actions. CircleCI in particular is known for very fast startup times and we're looking to ensure we keep up or get even faster. Jenkins is largely seen as a legacy tool, and most people we speak with are interested in moving off to something more modern. We are addressing this with our Jenkins Importer category which is designed to make this as easy as possible.
From GitHub's 2023 Roadmap, we are seeing GitLab-reminiscent features which include Pull Request Merge Queue, akin to Merge Trains with a fit-finish that we aim to make easier in gitlab#294169. Also to note is an emphasis on governance and controls with Audit Log streaming, bringing parity to the capabilities GitLab has created with the Compliance group's Audit Event streaming.
There are a few key findings from the Forrester Research analysts on our CI solution. GitLab is seen as capable as the solutions provided by the hyperclouds themselves, and well ahead of other neutral solutions. This can give our users flexibility when it comes to which cloud provider(s) they want to use. We are also seen as the best end to end leader, with other products not keeping up and not providing as comprehensive solutions. What this tells us is that it is important for us to continue to innovate and make it hard or even impossible for competitors to maintain pace.
As such, our path to improving our analyst performance matches our solutions above in terms of staying ahead of our competitors.
The Field teams are typically most interested in uptier features like Premium and Ultimate. The top requested issues in these tiers include a Group Level Dashboard and adding metrics for pipeline and job data to be exported for OpenTelemetry. Also important for the sales team is gitlab#205494 which will allow for easier use of GitLab's security features when not using GitLab's CI.
Our top customer issues (search results) include the following:
Another item with a lot of attention is to normalize job tokens in a more flexible way, so that they can have powerful abilities when needed and still not introduce security risks (gitlab#3559).
We also have a few issues about making variables available before includes are processed, however there is a "chicken and egg" problem here that has been difficult to solve. Child/parent pipelines solves some use cases, but not all. There are two related epics here, Use a variable inside other variables in .gitlab-ci.yml and Raw (unexpanded) variables MVC
Our top internal customer issues (search results) include the following:
In discussing the second issue with customers we have learned that there are two use cases for this: 1. Labeling before pipeline execution of things like long running integration tests which was done in gitlab#372538 with the new workflow:name keyword and 2. Dynamic labeling based on results within the pipeline. We will consider both as we work towards the MVC and think about the pipeline search experience.
Our top dogfooding issues (search results) are:
Looking to the future, we have plans to help you better monitor and understand your pipeline epic#4794. Having details about pipeline activities (such as job duration) will allow you to see and react to what's happening while your pipeline is running. Beyond using data simply for reactive purposes, we have plans for a customizable UI for historical pipeline analytics so you can see the trends that will guide your planning and decision-making.
We'd love to create a holistic approach to automatically merging when pipelines succeed via gitlab#8128, which offers great collaboration between Code Review and Continuous Integration.
Even further into the future, we are looking to expand insights and predications of CI use to help you reduce waste in our 3-year vision via gitlab&4793.