How do merge queues affect my metrics?
GitHub supports merging pull requests using a merge queue. This doesn't affect the definitions of cycle time or DORA metrics.
Last updated
Was this helpful?
GitHub supports merging pull requests using a merge queue. This doesn't affect the definitions of cycle time or DORA metrics.
Last updated
Was this helpful?
In regular trunk-based development, the stops once the PR is merged. This can be thought of as “concluding” the work on that PR.
Using , engineers often conclude their work on the pull request by adding it to the merge queue, from which it eventually gets merged to the main branch. However, before the PR passes all the checks required by the merge queue, and is actually merged, Swarmia will keep counting time towards the “Time to merge” of that PR.
This ensures that, when looking for bottlenecks in your pull request cycle times, a congested merge queue will be correctly visible as the thing you should focus on to reduce cycle time.
Also, if a PR is bounced back from the merge queue due to CI failures, its “Time to merge” will continue until the problem is corrected, and the pull request is merged to the main branch. This helps you notice if many of your PRs tend to bounce back from the CI, and are then forgotten about.
The above applies equally to , where pull request cycle times are involved. Specifically, your "Time to deploy" will only start counting after a pull request has successfully exited your merge queue, and has been merged to your main branch.