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 categories that are critical for success in this stage; each one is intended to represent what you might find as an entire product out in the market. If you have thoughts or questions on any of these, feel free to jump into the conversation in the vision epic.
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.
Learn more • Documentation • Vision
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.
Testing to ensure usability flows work and are actually understandable and valuable to your users.
Beyond being a compliance requirement in many cases, accessibility testing is the right thing to do.
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.
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.
triggerability Premium 2018 Vision
write_registrypermission to Deploy Tokens 2019 Vision
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!