Engineering teams no longer have to choose between Git blame or Git activity when it comes to assigning the best PR reviewer — they can now have both.
Enhance your current CODEOWNERS workflows with new dynamic pull request routing and classification by gitStream, a PR automation tool built around ensuring that your code is getting the highest quality review possible.
Year after year, research from DORA has maintained that by reducing manual work in the code review process, engineering teams can decrease change failure rate up to 40% and reap the benefits of higher ROI on engineering. It was with this data in mind that GitHub launched CODEOWNERS in 2017, thereby ushering in a new era of agile centered around workflow automation.
And while the widespread adoption of CODEOWNERS has been a great first step toward continuous merge, it has remained a one-dimensional solution. While CODEOWNERS does allow users to assign developers or teams to specific files, it does not take into account more dynamic data, like history, activity, developer expertise, or team workload.
Ensure the Highest Quality Review for Every PR
For engineering organizations looking to boost efficiency, the pull request review process is the best place to start. If you’re interested in enhancing your current CODEOWNERS workflow, here are new rules that will make your pull request reviews more effective:
- Code Experts: Authorize experts only for sensitive code
- High-Risk Tags: Let DevSecOps take the reins on high-risk work
- Missing Tests: Mark PRs without tests
- 2 Reviewers: Require 2 reviewers for complex PRs
Authorize Experts Only For Sensitive Code
When it comes to high-risk code, it’s imperative that changes are thoroughly reviewed by the most qualified person before they are deployed.
As such, one of the most popular gitStream rules is the ability to assign codeExperts to a review.
gitStream’s proprietary algorithm takes into account which developers have the most commit activity and knowledge on the files in question, then assigns them to review that PR automatically.
This way, the code expert can provide specific and informed feedback, rather than general comments that may be lacking vital context.
Let DevSecOps Take The Reins on High-Risk Work
Many dev teams love CODEOWNERS because it allows them to flag risky code by file or directory. With gitStream, users can also alert users based on code changes relevant to their team.
This is especially useful for reviews in sensitive areas of the codebase. For example, DevSecOps can flag risky code terms to ensure that PRs containing those terms are reviewed by their team.
In the example above, a gitStream user has defined a required field: description. Doing so will route all PRs with this component to DevSecOps every time.
Mark PRs without Tests
gitStream can also flag high-risk PRs in the pipeline, so engineers can spend their time on what matters most and catch bugs before they happen.
Whenever a PR without a test is opened, gitStream applies a bright red label.
Then, once the tests are added and committed, gitStream will automatically remove the label.
Require Two Reviewers for Complex PRs
Historically, when engineering teams have wanted two approvals on a complex PR, they’ve had to increase the required reviewer count for all PRs using GitHub repo settings.
This lack of flexibility within GitHub has forced engineering managers to choose between two evils: either assigning developers to more PRs than necessary or forgoing a second set of eyes on sensitive reviews.
gitStream solves for this dilemma by allowing users to assign two reviewers for PRs they deem complicated or high-risk.
In the example above, the user has added a rule that requires two developers to approve PRs with more than 100 lines of code changed under the src directory.
Help Your Dev Team Ship Code 44% Faster
With all that said, code quality is only one side of the equation. Top-performing engineering organizations must also optimize for speed to remain competitive in a down economy.
And it’s a common misconception that engineering teams must sacrifice code quality at the expense of pace. Rather, DORA research has “consistently shown that speed and stability are outcomes that enable one another.”
To this end, gitStream can also help decrease cycle time up to 44% by enabling developers with:
- Auto-Approvals: Approve safe changes automatically
- Reverse CODEOWNERS: Share knowledge across teams
- Deprecated API Alert: Request changes on deprecated APIs
Approve Safe Changes Automatically
Most PRs with simple revisions to documentation don’t need to take up your engineers’ precious time. Now, users can leverage gitStream to verify and auto-approve all documentation changes.
In the example above, the files context is checked by an allDocs filter that verifies the PR only contains document files.
Share Knowledge Across Teams
As important as it is to keep your developers unblocked day-to-day, it’s also critical to ensure that your team is improving month-over-month.
One of the easiest ways to do this is to let gitStream assign engineers to PRs based on their lack of knowledge. This can be a great way to familiarize devs with new areas of the codebase and facilitate knowledge sharing across your team.
As seen in the rule below, by setting lt to 50, only those who contributed less than 50% of lines overall will be assigned to the PR.
Request Changes on Deprecated APIs
Another popular gitStream rule is the ability to trigger a change request automatically whenever a PR includes use of a deprecated API. This allows engineering managers to encourage best coding practices on their team while remaining hands off.
This way, whenever a developer accidentally opens a PR using an old API, they will get the following automated alert redirecting them toward the preferred API.
Transition from Static CODEOWNERS to a Dynamic Review Policy
As with the launch of CODEOWNERS in 2017, gitStream marks a shift in the way developers will automate their workflows for years to come. Gone are the days of a one-size-fits-all approach to code reviews.
And unlike CODEOWNERS, which involves manual upkeep as teams and priorities shift, gitStream was built for scale, with highly customizable rules and little to no maintenance.
Setting up gitStream takes less than 3 minutes. Watch our installation tutorial below and set up your first rule today.
