Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md: How we calculate DORA #341

Merged
merged 1 commit into from
May 9, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,7 @@ They are:
- [Using Docker](#-using-docker)
- [Manual Setup](#%EF%B8%8F-manual-setup)
- [Usage](#-usage)
- [How we Calculate DORA](#-how-we-calculate-dora)
- [Roadmap](#%EF%B8%8F-roadmap)
- [Contributing guidelines](#%EF%B8%8F-contributing-guidelines)
- [Security guidelines](#%EF%B8%8F-security-guidelines)
Expand Down Expand Up @@ -318,6 +319,37 @@ To set up middleware locally, follow these steps:
- See Dora Metrics for your team.
- Update settings related to incident filters, excluded pull requests, prod branches etc to get more accurate data.

# 📖 How we Calculate DORA

Middleware can display DORA Metrics using exclusively GitHub Data. The aim is to provide DORA metrics to anyone and everyone using their Git data, regardless of other integrations.

DORA metrics are derived from Pull Requests, Deployments, and Incidents.

For simplicity, we synchronize your Pull Request data and classify reverted Pull Requests as incidents and merged Pull Requests as Deployments.

**Lead Time for Changes**

- Lead time consists of First Commit to PR Open time, First Response Time, Rework Time, Merge Time, and Merge to Deploy Time.
- When calculating DORA using git-based data, PR merges are regarded as deployments, hence the merge to deploy time is considered as 0, while the rest of the time components remain the same.

**Deployment Frequency**

- This metric gauges how frequently code changes are deployed to production.
- When considering PR merges as deployments, this can also represent the daily/weekly/monthly frequency of PR merges.

**Mean Time to Recover (MTTR)**

- MTTR measures how swiftly a team can restore service after a failure occurs in production.
- The team's average incident resolution time is utilized to compute its MTTR.
- When treating Revert PRs as incidents, the resolution time for an incident is calculated from the creation of the original PR to the merging of the revert PR.

**Change Failure Rate (CFR)**

- CFR quantifies the percentage of changes that result in a service impairment or outage in production, aiding in the evaluation of deployment process stability and reliability.
- CFR is computed by linking incidents to deployments within an interval; each deployment may have several or no incidents.
- Deployments that can be linked to any incident are considered as causing a failure or outage.
- The fraction of deployments causing outages to the total deployments in an interval is used to determine the CFR.

# 🛣️ Roadmap

Coming Soon!
Expand Down