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.
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.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, which enables delivering secure software efficiently 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 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.