...
Why Time to Merge matters
Code reviews are an important part of the software development lifecycle because they provide the ability for code written by team members to be peer reviewed and assured for quality before the code is merged to a single branch. Reviewing pull requests can also be one of the most time consuming activities of a team’s software development process.
We measure Time to Merge because code reviews can often get blocked, impacting how fast you can ship your product to your customers (additional insight that can be gleaned from viewing your team’s Cycle Time).
Optimising Time to Merge will improve the time it takes your team to deliver value to your customers, as well as improving the quality of the value you deliver. When done well, the code commits and their attched attached messages within a Pull request PR tell a story to people examining code at a later date, improveing improving maintainability and serviceability of the code base.
What ‘good’ Time to Merge looks like
Mature Time to Merge practice looks like
...
Small pull requests are easier to review, making it more likely for code to be thoroughly reviewed before approval. It helps to speed up the review, reduces risk of introducing bugs into the codebase, helps not block other developments and speeds up the product development process.
Common practice suggest developers should review Pull Requests no more than 200-400 lines of code (LOC) at a time. The brain can only process so much information at a time. Beyond 400 LOC, the ability to find defects diminishes.
Research also indicates that a review of 200-400 LOC over 6-90 minutes should yield70-90% defect discovery.
Large pull requests tend to be glazed over and rubber stamped, limiting the effectiveness of defect detectiondevelopers reviewing and merging PRs on the same day they were opened.
This is enabled by the author’s discipline to create small pull requests, constructed with titles that are self-explanatory and descriptions that provide strong context and reason behind what outcome the code is meant to achieve. These practices go a long way in minimising the need for peers to add comments or tasks, and asking for further information to help with their understanding. Speeding up the review workflow by not blocking peers and being able to merge code sooner goes a long way toward building your team’s delivery success.
How Umano measures Time to Merge
Umano measures Time to Merge by observing for For each Pull Request merged during the given interval, Umano measures Time to Merge by observing the time from when the Pull Request was created to the time when it was merged into mastera single branch.
Practices that influence Time to Merge
...
Included | Not included |
|---|---|
All Pull Requests in selected repositoriesx. | All declined or open PRs that are not merged. |
Tips for improving Time to Merge
...
| Tip |
|---|
Describe your changes well in within each commit |
| Tip |
|---|
Reviewers should ensure Ensure the commit history is excellent, that good changes are made quickly, that the code review is performed and that they understand it is understood what is being changed , from the perspective of someone examining code in the future. |
| Tip |
|---|
Encourage a culture where all team members can share in the responsibility of being a reviewer and be proactive in picking up a PR for review |
| Tip |
|---|
Ensure there is a balance between flow your team’s speed and ensuring the quality of your team’s PRsreview, a balance best discussed in your team’s stand-ups or retrospectives |
Resources
Dias, H., The anatomy of a perfect pull request, 2018, <https://medium.com/@hugooodias/the-anatomy-of-a-perfect-pull-request-567382bb6067 >
Osepchuk, B., Optimal pull request size, 2017, <https://smallbusinessprogramming.com/optimal-pull-request-size/>
Riosa, B. The (written) unwritten guide to pull requests, 2016, <https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests >
Dias, H., The anatomy of a perfect pull request, 2018, <https://opensource.com/article/18/6/anatomy-perfect-pull-request>
Hewa, G., How Big is Your Pull Request?, 2017, <https://hackernoon.com/how-big-is-your-pr-32c4d67ad76c>
Yu, Y., Wang, H., Filkov, V., Devanbu, P. and Vasilescu, B., 2015, May. Wait for it: Determinants of pull request evaluation latency on GitHub. In Mining software repositories (MSR), 2015 IEEE/ACM 12th working conference on (pp. 367-371). IEEE.
...