Don’t bother reviewing pull requests….
… if the build and test pipeline does not pass.
After stumbling across this recent community post, it inspired us to write a little something about pull requests, reviewers, notifications and what to avoid.
Adding reviewers to pull requests before ensuring the code successfully passes the build and test pipeline is an inefficient practice that slows down development velocity. When the build fails, reviewers end up evaluating code that will soon be outdated, wasting their time and necessitating multiple rounds of review.“person frustrated at computer” lol RIP Shutterstock
The Problem at Hand
The premature addition of reviewers leads to inefficiency. Reviewers waste time on code that’s not yet ready, reviewing and approving changes that will be obsolete after test fixes are committed. This inefficiency requires additional review cycles, delaying the development process. The result? A cycle of re-reviews and re-approvals that could have been avoided.
A Streamlined Solution
The solution is straightforward: configure the development workflow to add pull request reviewers only after the build and test pipeline has successfully completed. This ensures reviewers only see code that’s ready for their evaluation, streamlining the review process.
Why This Approach Makes a Difference
- Efficiency: Reviewers engage with code that has already passed initial quality checks, reducing the need for multiple review cycles.
- Focus on Quality: With preliminary tests passed, reviewers can concentrate on the code’s quality, architecture, and adherence to best practices.
- Timeliness: Reviews are conducted when the code is actually ready, avoiding delays in the development process.
- Confidence: Reviewers can trust that the code meets basic quality standards before they even look at it, allowing for more focused feedback.
Workzone Cloud
This is an important issue that we wanted to address with our app Workzone for Bitbucket (cloud).
Here is a link to Workzone’s documentation space highlighting how to create a configuration that adds reviewers only after a successful build, i.e. also allowing them to only receive the notification after a successful build.
So, where does this leave us?
By only adding pull request reviewers after the code has successfully passed build and test pipelines, teams can significantly improve the efficiency and effectiveness of the review process. This not only saves time but also ensures that reviews are more focused and constructive, ultimately speeding up the development cycle and improving code quality
Visit Workzone for Bitbucket today, you won’t regret it.
As always,
Happy coding.
Sean
