Skip to content

DORA4: API support for Change Failure Rate - Backend service

Release notes

The user should be able to use the API to present the change failure rates data in an external tool.

Change failure rate - what percentage of changes to production or released to users result in degraded service (generally requiring a rollback or hotfix/patch)

Problem to solve

The fourth DORA4 metric is Change Failure rate which is the percentage of changes introduced to a production environment that cause a failure scenario. These metrics enable executives who are investing in DevOps transformation to understand ROI on processes they are implementing and tools they have purchased. Changes in these metrics easily become KPIs for those teams.

  • As an executive investing in DevOps, I want to see my ROI. I want to see an improvement in the Change Failure Rate of my dev team. This will most likely drive the KPIs of my team.
  • As a developer leader, I want to see that the team is improving by measuring the change failure rates and comparing it over time (over sprints).
  • As an analyst, I want to import the data from GitLab into an external monitoring tool, so I need API support to poll the data.

Intended users

User experience goal

The user should be able to use the API to retrieve the change failure rate data for use in an external tool.

Proposal

The DORA metrics API should include change_failure_rate, measured as "the number of incidents divided by the number of deployments to a production environment in the given time period". What needs to be implemented:

Technical notes

In scope of this issue we need to rework DailyMetrics#refresh! to accept list of metrics to refresh.

Not in scope of this issue:

  • Group-level and instance-level calculations.
  • GraphQL equivalent of the REST endpoint.
  • As parameters there should be a configurable timestamp - the default time, if not set should be 30 days.
  • Support for the environment that there was a merge for. In the true sense of DORA 4 - this is only meant for production, but there may be more than one prod environment and/or users may interested in non-prod environments.
  • Measuring how many rollbacks occurred (redeploy of an older pipeline than the one in production)
  • Measuring the degradations reported in an MR deployed to production. For example: counting MRs associated with degradation in metrics like memory usage.

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.

Edited by Pavel Shutsin