Provide a way to monitor rollbacks
Release notes
The user requesting this feature provided the following use case:
We would like to monitor our deployments, to have an overview of whether a team might be moving too fast or not, and this velocity is directly resulting in too many deployments, e.g. deployments resulting in rollbacks, incurring direct and indirect cost. We can use this metric to set up quality gates that would require manual approval rather than automatic deployment, thus we reward teams moving at a reasonable pace - deploying fast, but with few or no rollbacks needed - with less checks and easier deployments.
Problem to solve
This point could do with further investigation, but from my own experiments: it is difficult to retroactively identify rollbacks with certainty. The metrics provided would have to be idempotent and unambiguous to be useful the way the customer is describing
Intended users
Unknown; I will clarify and update. My understanding is that this is for management to measure the impact of velocity.
Best guess: Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
- Sidney (Systems Administrator)
- Rachel (Release Manager)
- Simone (Software Engineer in Test)
- Allison (Application Ops)
- Priyanka (Platform Engineer)
User experience goal
The client organization wants to use this information to make quality decisions, specifically how it is effected by velocity - the user experience goal would be to provide this information, and being sure it's accurate, usable and consistent.
Proposal
The user would like to be able to easily and reliably determine how many deployments failed and had to be rolled back. We discussed a few solutions and the customer was open to all of them; they include:
- Have a metric included with the metrics being exposed by the relevant exporter (for consumption by promentheus)
- Track this value programmatically with custom scripts included in their CI or by firing external code with hook
Permissions and Security
What permissions are required to perform the described actions?
Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate?
Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Yes
https://docs.gitlab.com/ee/user/permissions.html
-
Add expected impact to members with no access (0) -
Add expected impact to Guest (10) members -
Add expected impact to Reporter (20) members -
Add expected impact to Developer (30) members -
Add expected impact to Maintainer (40) members -
Add expected impact to Owner (50) members
Please consider performing a threat model for the code changes that are introduced as part of this feature. To get started, refer to our Threat Modeling handbook page https://about.gitlab.com/handbook/security/threat_modeling/#threat-modeling.
Don't hesitate to reach out to the Application Security Team (@gitlab-com/gl-security/appsec
) to discuss any security concerns.
-->
Availability & Testing
Available Tier
- Free
- Premium/Silver
- Ultimate/Gold
Feature Usage Metrics
tbd
Links / references
This 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.