Managing effective and layered reviews through Github Teams and CodeOwners file in Github
Our team (facility data hub team) at Wayfair had challenges in asking senior engineers and tech leads for code reviews. Code reviews are an integral part of the process to ensure that a commit that lands into production is tested well, readable and maintainable. Prior to our discovery of this way of adding people to the code reviews, we used to have single CODEOWNERS file with each user listed in the file. This gave us two problems. When a PR gets raised, its often becomes difficult to ask for reviews from senior engineers and tech leads. Let me show you a glimpse of how it looked like
and this is how it appeared in Pull Requests. It’s so awful to look at the dreadful list and adding new people to the group required a new change request to be merged in every time.
To simplify the engineering bandwidth to simplify communication and ease of process, what we did instead we created two Github teams, one for level 3 engineers and one for level 4 engineers. The level3 engineers are supposed to take the first look at the code and ensure the code adheres to the guidelines set by the team and code is safe to merge and a the reviewer waits for a final approval for level 4 engineers/staff engineers/engineering managers who acts a final guardrail to ensure the change request is safe. This ensures the code goes through 2 layers and gets a good set of eyes before it lands. Below is the image where we created a team for level 3 engineers/senior engineers,
The final list would look something like this.
After creating this, you could do a final change request which changes the CODEOWNER file to the new teams instead of individual engineers.
After everything is done, you should change the branch protection rules right below, this is usually found under your repository settings.
Ensure the following checkboxes are ticked, especially the following ones:
Require Approvals [ Required number of approvals before merging: 2]
After we are done with the changes, this is how the final result looks like when new Pull Requests arrive. much cleaner and much easier to maintain engineering reviews if your organisation requires layered code reviews.
