GitHub user csepulveda created a discussion: Calculate Change Failure Rate and Failed Deployment Recovery Time Only using Github and Issues.
Hello everyone, I need some guidance on how to achieve this without having to make heavy custom modifications to the code, since so far I haven’t found a clean way to do it. Here’s some context: At the company where I work, we want to implement DORA Metrics using Devlake. We use GitHub, and we want to track Change Failure Rate and Deployment Recovery Time using GitHub Issues. The main problem we’re facing is how to modify the default behavior. When using DevLake with GitHub Issues, the Change Failure Rate works correctly for us: we tag a deployment as failed based on the time when the issue is created, and that’s fine. However, the issue is with Deployment Recovery Time. In many cases, a bug is introduced in a PR today, but we might not notice it until next week or even after several more PRs have been merged and deployed. Because of this, measuring recovery time purely based on the issue creation date is not really accurate. >From our perspective, when creating an issue, we need a way to: Explicitly define which PR introduced the error (instead of just using the issue creation date). Define which PR fixed the issue, and calculate the recovery time using the deployment timestamp of: the PR that introduced the bug and the PR that fixed it instead of just using the next deployment after the issue was created. How do you handle this in your environments? I was thinking about modifying DevLake’s components and using labels or metadata in the issues to link: the PR that introduced the bug, and the PR that fixed it But this feels very specific to our workflow, and it would likely force us to maintain a permanent fork, which we want to avoid. GitHub link: https://github.com/apache/incubator-devlake/discussions/8651 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
