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.

 

2.png
“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.

 

Pull Request Meme.jpg

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

Izymes

0 comments

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events