The Lead time for changes indicates the time it takes to deploy a commit to production.It measures the time elapsed between the first commit and the deployment of a code review, thus its integration. This can be patches, enhancements, or new features.
You can display the change time for the last month, the last three months, or the last 6 months. You can also specify the environment to display, either production or staging.
Reading the graph
For the following graph, the time period displayed is the last three months and overall we can see that the team takes, on average, 3 days and 8 hours to deploy a commit in production for this period. According to the 2022 State of DevOps report, this restoration time is in line with the evaluation criteria for a high-performance team.
The graph also shows the time required to complete each step in the process. In this team's case, we can see that the bottleneck is at the deployment stage.
A short lead time for changes demonstrates that your processes are efficient and quickly deliver value to your customers, allowing you to get quick feedback on your product. In the case of the team used in this example, the bottleneck at the deployment stage should be addressed quickly, as it prevents the delivery of value to the customers.
Psst! Want to learn more about potential solutions to improve your lead time for changes? Check out our comprehensive Guide to Understanding DORA Metrics!
By clicking on the tooltips for each stage, you will get the following information.
- Coding: The coding phase reflects the time from the first commit to the moment the pull request is issued or opened.
- Pickup: The pickup phase is the time from when the pull request is opened to the first interaction (e.g., comment, reaction, thumbs up). This phase is important as it may reflect a bottleneck in your flow like idle pull requests or where the pull requests get stuck.
- Review: The review phase represents the time from the first interaction (e.g., comment, reaction, thumbs up) to when the pull request is merged. It reflects the time to review the pull request and the back-and-forth between team members before it is merged.
- Deployment: The deploy phase represents the time from the pull request being merged to it being deployed.
Calculating the metric
When calculating the metric, Axify only considers deployments that occur when a pull request is merged.
If a deployment occurs during the "pickup" or "review" phase of a pull request, the deployment is ignored for this metric. However, Axify will consider this deployment in calculating the deployment frequency.
Therefore, Axify identifies and measures deployments as follows:
- Only successful deployments are counted.
- We target deployments per day.
- Only one deployment is considered in case of a deployment that fails and is redeployed later (after rollback).
- If the unique ID (a.k.a. the "Sha", or "hash") is used in 2 deployments, an average is made so that only one deployment is compiled.
All deployments are considered for the selected environment.
Deployment data can come from several sources on the same webhook or on several webhooks.
To learn more about the variation indicator and its calculation, check out this article!