Waydev’s DORA Metrics report is designed for engineering leaders to track and measure software delivery performance metrics.
In order to calculate the four DORA metrics, Waydev requires users to set up release and incident detection on the Settings page. Here is the DORA Metrics setup page.
When viewing the DORA Metrics dashboard in Waydev, you can filter data by teams and applications.
Select how you want to visualize your DORA Metrics, based on Chart Type (Bars, Area, Stack) and View Type (by Month, Week or Auto) from the upper right corner of the widget. You can visualize each metric in a different way.
Waydev’s DORA Metrics report includes the four key metrics that engineering leaders can use to track software delivery performance:
Deployment Frequency: measures how often code is deployed into production, including bug fixes, capability improvements, and new features.
Lead Time for Changes: measures the amount of time it takes for code to get into production from the first commit made.
Change Failure Rate: measures the percentage of deploys that cause a failure in production.
Mean Time to Recovery: measures the amount of time it takes to recover from a failure in production.
The Engineering Metrics Benchmarks have been derived from a comprehensive study of 1,971 development teams and 847,000 code branches. This represents a major milestone since the publication of DORA's research in 2014, as engineering teams now have the opportunity to gauge their performance against robust, data-driven industry benchmarks.
For every single metric, an icon representing the corresponding benchmark will appear in the metric widget. By simply hovering over this icon, you will be presented with detailed benchmarks for that particular metric and their associated values.
The Deployment Frequency measures how often code is deployed into production.
To see all the builds and deploys that occurred in the selected time period across the selected applications, scroll down on the Dora Metrics page and select View Builds/Deploys.
You will see a breakdown of builds/deploys that occurred in the selected time period across the selected applications, the environment, the number, their corresponding repository, the start date, and the finished date.
Lead Time for Changes measures the elapsed time between the first commit and the deployment to the final environment.
To see a Pull Request breakdown of all the Pull Requests analyzed in the selected time frame, scroll down and click View Pull Requests. To zoom into a particular Pull Request, click the "More" button corresponding to that Pull Requests.
Once clicked, a modal will appear containing more information, such as the date of the first commit, when the Pull Request was created, what time the Pull Request was reviewed and merged at, the total number of files and lines of code affected, and the Lead Time for Changes for the Pull Request.
The Lead Time for Changes can be broken down into Coding Time (time elapsed between the first commit made and a Pull Request being opened), Review Lag Time (time elapsed between a Pull Request being opened and the first review made), Review Time (time elapsed between the first review and the Pull Request merged), and Deploy Time (time elapsed between the Pull Request being merged and its deployment to the final environment).
The modal also contains a "Go To Pull Request" button, which takes you directly to the Pull Request page in your Git Provider, and shows all associated code commits, deploys, issues (tickets), and Pull Request reviews.
The Change Failure Rate metric indicates the percentage of deployments that lead to failures in production.
Change Failure Rate is calculated by dividing the total number of failed deploys by the total number of deploys in a given time period. A deployment is considered "failed" if one or more incidents occur between deployments.
To view all failed deployments for the selected filters, scroll down and click View Failures. You can view the deployment name, environment, number, repository, start date, and finish date.
The Mean Time to Recovery measures the time it takes to recover from a failure in production. It analyzes the elapsed time between a failed deployment and a successful deployment on the same repository and branch.
Calculation of Mean Time to Recovery: For each detected incident, we calculate the Cycle Time. The Mean Time to Recovery is the total Cycle Time of all incidents divided by the number of incidents.
To see an Incident Pull Request breakdown in the selected time frame, scroll down and click View Incident Pull Request. To zoom into a particular Pull Request, click the "More" button corresponding to that Pull Requests.
Once clicked, a modal will appear containing more information, such as the date of the first commit, when the PR was created, what time the PR was reviewed and merged at, the total number of files and lines of code, and the Lead Time for the PR.
The Lead Time breaks down into Coding Time (time spent between the first commit and a pull request being opened), Review Lag Time (time spent between a Pull Request is opened and the first review), and Review Time (Time spent between the first review and merge).
The modal also contains a "Go To Pull Request" button, which takes you directly to the PR page in the Git Provider.
With the help of the DORA Metrics, you will be able to:
- Measure your teams’ DORA Metrics automatically and increase software delivery velocity.
- Compare your teams’ DORA Metrics to industry benchmarks to spot areas of improvement.
Updated 5 months ago