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.
Thanks for visiting this category page on Continuous Verification in GitLab. This page belongs to the Respond group of the Monitor stage, and is maintained by Alana Bellucci who can be contacted directly via email. This vision is a work in progress and everyone can contribute. Sharing your feedback directly on issues and epics at GitLab.com is the best way to contribute to our vision. If you’re a GitLab user and have direct knowledge of your need for continuous verification, we’d especially love to hear from you.
"Continuous verification is the process of querying external system(s) and using information from the response to make decision(s) to improve the development and deployment process."
Observability is the ability to measure the internal states of a system by examining its outputs. Users collect telemetry data so that they can determine the current state of the system.
Monitoring is looks at a system to determine if the system state is within the expected range.
In the past, when users had less access to telemetry data, we had to be more selective on what we instrument. Today, there are many frameworks, platforms, and tooling that enable users to collect a variety of telemetry data. This enables many teams to actually build observable systems.
Continuous verification is related to observability and monitoring, however, continuous verification aims to improve the development or deployment process. Continuous verification can be accomplished by looking at the outputs of observability systems during pipeline runs to see if a deployment is successful. Similarly, we can use other existing tools, such as a smoke test, or a container security tool to improve processes.
The GitLab CI/CD pipeline is extremely flexible. You can add any number of stages and jobs. Each job can be a continuous verification job, such as scanning for vulnerability, which helps you to continuously improve your development and deployment processes.
However, we want to specifically focus on helping GitLab user's abilities to improve deployments.
When deploying an application, I want to verify that the application is in a performant and healthy state, so I can be assured that the deployment isn't causing any abnormalities.
Job statements | Maturity | Confidence | Source |
---|---|---|---|
When planning to deploy changes to an application, I want to verify that the application is currently performant and in a healthy state, so that I can have confidence that known issues won't interfere with my deployment. |
|
Researched | Issue |
Immediately after a deployment, I want to verify that the application is performant and in a healthy state, so that I can automate the rollout or rollback of the changes. |
|
Researched | Issue |
GitLab Continuous Verification enables users to confidently deploy and verify successful deployments or quickly identify anomalies.
We intend to build for Ingrid (Infrastructure Operator) and Sasha (Software Developer).
Ingrid uses GitLab continuous verification to set up deployments on behalf of her development teams. Sasha uses what Ingrid provides to confidently and efficiently deploy.
We need to define how we will make iterative progress in this category post our MVC, environtment action:verify
TBD
We are currently working to mature the Continuous Verification category from minimal
to viable
. Definitions of these maturity levels can be found on GitLab's Maturity page. While we are still working on validating the requirements for this first iteration, we'd love your input on the Continuous Verification: Viable Maturity Plan epic.
We need to identify and validate paths forward beyond our MVC. Some ideas being discussed internally include:
As of early 2022, Continuous Verification
doesn't have it's own magic quadrant, but the term "continuous verification" is seen in one-off mentions throughout publications. We will be working with analysts to better understand what the trends are for observability data are around automation and machine learning. These will help inform future iterations of GitLab's solution for Continuous Verification.
Update - In August 2022, Gartner published Innovation Insight for Continuous Quality (internal).
Key findings, recommendations, and highlights include: