The Verify stage of the DevOps pipeline covers the CI lifecycle as well as testing (unit, integration, acceptance, performance, etc.). Our mission is to help developers feel confident in delivering their code to production. Please read through to understand where we're headed and feel free to jump right into the discussion by commenting on one of the epics or issues. If you'd like to discuss this vision directly with the product manager for Verify, feel free to reach out to Brendan O'Leary via e-mail, Twitter, or by scheduling a video call.
CI was one of the first "additions" to GitLab where there was a hotly contested debate about placing it into a single application. As the first stage in the Ops Department, Verify has the unique ability to tie together what developers are doing (every commit) with what operators need (reliable, tested deployments). Therefore, Verify will continue to strive to be a "shining city on a hill" of the tangible and emergent benefits of a single application, avoiding the pitfalls of legacy systems that optimize only for one stage of the DevOps lifecycle.
At the core, GitLab CI/CD was built from the ground up with speed and scalability in mind. This is reflected both in the product design and product vision (automated testing, testing all the things) To enable our users to go from monthly shipping releases to truly enabling continuous delivery, everything that we do must be concerned with the scalability and speed of continuous integration and testing.
Our users are solving some of the hardest problems on the cutting edge of software development. The promise of GitLab overall is to provide a simple, lovable application for the entire DevOps lifecycle. Many parts of that cycle - including Verify - are traditionally complex to solve. Our goal is to provide a lovable solution to these complex problems so that users focus on their code - not building a DevOps environment.
Often, when businesses invest in continuous integration, they can plateau once they have have the code building and tests running. However, to deploy effectively, we need to embrace code review, dependency assurance, security scanning and performance metrics for every commit. GitLab's vision for Verify is to help users accelerate their journey to DevOps maturity.
There are a few product categories that are critical for success here; each one is intended to represent what you might find as an entire product out in the market. We want our single application to solve the important problems solved by other tools in this space - if you see an opportunity where we can deliver a specific solution that would be enough for you to switch over to GitLab, please reach out to the PM for this stage and let us know.
Each of these categories has a designated level of maturity; you can read more about our category maturity model to help you decide which categories you want to start using and when.
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 "lovable" level of maturity.
Automatically analyze your source code to surface issues and see if quality is improving or getting worse with the latest commit. This category is at the "minimal" level of maturity.
Be confident in the performance of your changes by ensuring that they are validated against real world load scenarios. This category is at the "minimal" level of maturity.
Modern software is often delivered as a collection of (micro)services to multiple clouds, rather than a single monolith to your own data center. Validating complex interactions to ensure reliability of the system as a whole is more important than ever. This category is planned, but not yet available.
Testing to ensure usability flows work and are actually understandable and valuable to your users. This category is planned, but not yet available.
Beyond being a compliance requirement in many cases, accessibility testing is the right thing to do. This category is planned, but not yet available.
Compatibility testing is a broad discipline and includes things such as hardware testing for software that runs on different devices, as well as multi-cloud compatibility testing which is becoming more and more important in a cloud-based world where you don't want all your eggs in one basket. This category is planned, but not yet available.
In general, we follow the same prioritization guidelines as the product team at large. Issues will tend to flow from having no milestone, to being added to the backlog, to being added to this page and/or a specific milestone for delivery.
You can see our entire public backlog for Verify at this link; filtering by labels or milestones will allow you to explore. If you find something you're interested in, you're encouraged to jump into the conversation and participate. At GitLab, everyone can contribute!
Issues with the "direction" label have been flagged as being particularly interesting, and are listed in the sections below.
on-branch, new-branch, empty-branchkeywords for only/except
There are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!