<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> 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 <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> 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 <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) * [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor) --> * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> The user should be able to use the API to retrieve the change failure rate data for use in an external tool. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> The [DORA metrics API](https://docs.gitlab.com/ee/api/dora/metrics.html) should include `change_failure_rate`, [measured as](https://docs.gitlab.com/ee/user/analytics/) "the number of incidents divided by the number of deployments to a production environment in the given time period". What needs to be implemented: * Backend service to perform calculations. (This issue) * REST API enhancement. ([Separate issue](https://gitlab.com/gitlab-org/gitlab/-/issues/355013)) * REST API documentation. ([Separate issue](https://gitlab.com/gitlab-org/gitlab/-/issues/355013)) ### Technical notes In scope of this issue we need to rework [DailyMetrics#refresh!](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/dora/daily_metrics.rb#L30) 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](https://docs.gitlab.com/ee/user/project/merge_requests/testing_and_reports_in_merge_requests.html) in an MR deployed to production. For example: counting MRs associated with degradation in [metrics](https://docs.gitlab.com/ee/ci/metrics_reports.html) like memory usage. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->