Edit: This feature was originally planned for the 13.5 release but has now been rescheduled to the 13.7 release in order to address some performance improvements.
Requesting a code review is an important part of contributing code to any software project. However, deciding who should review your code and asking for a review are no easy tasks. Historically, teams making use of merge requests for their code review needs have used the "assignee" field for both authors and reviewers but this makes it hard for others to determine who's doing what on a merge request; for example, consider a merge request with a single author and 2 reviewers. If all parties are on the “assignee” field at once, it is hard for an external user to find out who to reach out for something specific.
The back-and-forth between authors and reviewers causes the author to go through MR history to find the original reviewer as well as unnecessary assigning back and forth from everyone. Peers who are coming on to assist cannot easily find relevant players for this merge request. Lastly, the merge request author does not know if a reviewer has reviewed but not approved the changes, or if more work is needed from them.
GitLab code reviews
Whether or not code is good quality can’t be taken on faith; code quality needs to be checked. GitLab makes it easy to collaborate on code reviews within a merge request. In GitLab, users can assign one or more code reviewers to a source project. Collaboration in merge requests with GitLab reviewers helps deployments go more smoothly. The code reviewer option in GitLab is available on GitLab Premium and GitLab Ultimate.
Merge requests and code reviews
The merge request Reviewers feature in GitLab allows for a review of your work and to see the critique progress status. The “suggest changes” feature lets a colleague suggest alterations that the original author can choose to accept or not, just with the click of a button. And, of course, every change made to a block of code can be reviewed before it goes live.
Feature branches and code reviews
Creating a new feature branch or new code automatically kicks off a merge request, and that is the place to request a code review. In the MR, inline code reviews can be performed either on a single line or multiple lines of code, and a reviewer can leave comments. A feature branch allows for changes to be made to the codebase without them moving onto the main default branch.
After the merge request and code review are complete, feature branches can be deleted to keep the source code repository clean as possible. It’s also possible to add time tracking to an MR to discern how long the process, including the code review, takes from beginning to end.
The merge request widget helps delete these feature branches once a merge request and code review are done. This can be set up to happen as you create the initial MR by choosing the “delete source branch when merge request accepted” selection. That way, the branch gets deleted after the MR is merged.
Improving code reviews
To bridge these gaps, GitLab 13.7 introduces merge request "reviewers," which easily allows authors to request a review as well as see the status of the review. By simply selecting one or more users from the "reviewers" field, the assigned reviewers will receive a notification of the request to review the merge request. This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review from a peer.
Screenshot from upcoming GitLab 13.7 release
What's next
Future improvements include suggesting the most relevant reviewers as well as streamlining the approval rules experience when paired with reviewers.
We are excited to see this feature ship soon to GitLab.com and for self-managed users on October 22nd. As always, we encourage you to participate in the conversation by visiting the related reviewers epic in the GitLab project.
