Deployment Frequency, one of the Four DORA Key Metrics is now available in Uplevel with additional updates to PR Throughput and Cycle Time.
Overview
Deployment Frequency, one of the Four DORA Key Metrics is now available in Uplevel with additional updates to PR Throughput and Cycle Time.
Uplevel data sources now include CI/CD data from GitHub Actions.
This release adds Deployment Frequency to help organizations understand how frequently they deploy code to production. Additionally, two existing Uplevel metrics, PR Throughput and Cycle Time, are being updated to clarify their distinction from the Four Key DORA Metrics.
Lead Time for Changes and Change Failure Rate will be released in the coming weeks.
Key Updates
Deployment Frequency
Deployment Frequency Definition:- Deployment Frequency is calculated as the number of successful deployments to production a group of people has in a given time period. It is an indication of how frequently and consistently teams are able to deliver new value to customers. A deployment will be associated to a segment of people if it contains the person who initiated the deployment or authored a PR that was included in the deployment.
- Deployments to production are estimated for each repository by the environment configured within Github Actions. Uplevel looks for environments that contain the strings
prod|live|release, but notpre-prod|pre-releaseand variants. If no environments match this expression, we default to an environment with the fewest deployments in the past 6 months. - Users will soon be able to configure deployment environments at the repository level in an upcoming release.
- Release Frequency has been removed from Uplevel. It served as an estimation of “releases” in the absence of CI/CD data. Specifically, it was calculated as the number of “releases” a group has in a given time period and was estimated by looking for code appearing in an estimated release branch. This metric was most accurate when teams had a branching strategy that included having development, staging, and production branches as an example. However, the majority of teams don’t use this strategy, increasingly defining releases from their CI/CD Tooling.
- For the reasons described above, as well as the upcoming Lead Time for Changes metric that leverages deployments, Uplevel is slightly redefining Cycle Time. It was previously calculated as the time from first commit to when the PR was merged into an estimated release branch; however, >95% of PRs were merged directly to a default branch and Uplevel did not have insight to how they were deployed to users. As a result, we have dropped the “Release” phase of Cycle Time.
- Cycle Time is now defined as the duration of time between the first commit to when the PR is merged. For the vast majority of PRs and teams, this will have a negligible effect on the teams’ measured Cycle Time.
- In a future update, teams will be able to change the coding start time to optionally leverage linked Jira data and better account for the time work on a PR really begins.
PR Throughput
- PR Throughput counts the number of merged PRs a group of people has collectively authored in a given time period. It is an indication of how frequently code changes occur, and whether that comes in at a consistent cadence or in waves. Because Deployment Frequency leverages CI/CD data and not all teams are using CI/CD, PR Throughput is applicable to any team that works with code to understand how teams are able to deliver value to users. For most teams, PR Throughput and Release Frequency (now removed) have equivalent data.
Frequently Asked Questions (FAQ)
How much does Release Frequency differ from PR Throughput?
Across Uplevel’s book of business, PR Throughput is typically 20% higher than our former Release Frequency metric. This can vary significantly from team to team depending on branching strategy, and branch names, however. For some teams that were merging directly to main or master or prod/production branches the metrics are completely equivalent.