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 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 daily 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 to detect problems before they intensify.
From this mission, our vision is that by 2028, GitLab CI will be seen as the market leader for programmable AI-powered CI/CD, proven to run at scale for all software development use cases.
We will execute this vision by:
.gitlab-ci.yml files.In addition to the vision outlined above, another goal is for CI/CD to be a critical enabler of the GitLab three-year strategy. Now, a CI/CD pipeline on its own, while critically valuable to the modern DevSecOps lifecycle, only tells part of the story of whether a software development team is delivering value as efficiently as possible. Therefore, our strategy over the next three years is to help businesses realize value faster by integrating the GitLab pipeline experience into areas of the platform focused on software delivery practice.
For example, a developer can view DevOps Research and Assessment (DORA) metrics at the aggregate level in the Value Streams Dashboard. However, providing the developer with the DORA metric for a specific commit within the CI/CD pipeline experience offers real-time visibility and empowers the developer to make immediate changes to improve business results.
The rationale for this strategy is as follows. There are various approaches in the industry today for authoring CI/CD workflows. Those options range from a declarative language such as YAML, an actions-style DSL, to procedural programming languages like Starlark. At the core of these various approaches is one constant - developers want simple-to-learn and use automation solutions regardless of the type of application they are developing. In the future, there will undoubtedly be new approaches for CI/CD pipelines entering the market. So, while the underlying automation authoring engine may change, the end goal of what we must achieve as software developers will remain the same.
Thus, the fundamental pillar of the GitLab Verify stage differentiation and platform support strategy is integrating the CI/CD experience at the developer persona level with other areas of the GitLab platform to enable the efficient delivery of secure software at scale.
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 FY25, check out our Verify Roadmap Issue Board.
There are important things we won't work on to focus on our one year plan.
Streamline your software development lifecycle with continuous, automated building, testing, and deploying of iterative code changes. This ensures the early detection of integration issues, bugs, and security vulnerabilities before deploying to production. This category is at the "complete" level of maturity.
Learn more • Documentation • Direction
Improve scalability of GitLab CI
Advanced features enable you to edit/compose a highly flexible CI/CD pipeline configuration to boost efficiency across a variety of projects.
Learn more • Documentation • Direction
Provide repeatable values to pipelines and jobs to drive efficiency. This category is at the "minimal" level of maturity.
GitLab Runner is an application to run the GitLab CI/CD jobs in a pipeline.
GitLab hosted Runners are managed by GitLab and can be used to run CI/CD jobs on GitLab.com or GitLab Dedicated.
Evaluate the status and performance of your runner fleet.
Code testing and coverage are important parts of a Continuous Integration framework, ensuring that source code is validated by test suites and individual pipeline components perform as expected. This category is at the "viable" level of maturity.
This category focuses on user needs of artifacts which are created as an output of a pipeline or job. This includes both the job’s artifacts, job logs and pipeline artifacts.
The framework to generate various report types based on job artifacts. Pipeline reports can leverage Pipeline Artifacts as a storage mechanism for aggregating results or persist data with a database schema.
Secure Artifacts focuses on the hardening of artifacts, to ensure the authenticity of artifacts.
Coordinate frequent merge requests and avoid merge conflicts with Merge Trains, preventing code commits from breaking default and main branches. This category is at the "viable" level of maturity.
Gain access to a live instance of your application for every commit, allowing you and stakeholders to ensure thorough validation and collaboration before changes are merged into the main codebase. This category is at the "viable" level of maturity.
Priority: low • 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.