This is the second in a series of blog posts looking at the challenges of code review and the ways a DevOps platform can help. Read the first post.
What is a code review, and why is it important?
Code review can be one of the most deceivingly difficult things in delivering software faster. Given the high stakes involved, we've made some key additions to our DevOps Platform that focus on making the code review process as seamless and effective as possible. We believe the number one way to make code reviews effective is to provide context.
Too often we think of code review tool features as only "reading" and commenting on others' code - but what a good code reviewer does is understand the entire context of the proposed change. Context-driven code reviews should include factors like the issue that spurred on the change, how the change impacts non-obvious things like code quality, security, and performance, and whether the code is maintainable after the change is in place.
Simplifying code reviews
Given all of that, we made the merge request the central point of change management and it's one of the key benefits of a DevOps Platform. Using a merge request allows code submitters and reviewers alike to have all of the information required to make the right decisions about a particular change. Making sure that everyone has the same information, and is as informed as possible about how a change will impact the project over all, leads to code reviews that are both quicker and more effective.
Over the last year we've added five features that help ease the code review pain. Here's a look at all of them:
1) Meeting you where you are
Some of the biggest code review changes involve meeting folks where they are - and allowing for a more natural feeling code review. As engineers, we spend most of our days glued to our IDE of choice. And we're used to code not just being static words on a screen, but also interacting and running that code to check its performance and outputs. That's why GitLab has brought a truly integrated experience to your development environment.
[Here's how to get started with a DevOps platform]
If you use Visual Studio Code as your main development environment like I do, you can now view merge requests directly in VSCode. In addition, you can comment and see comments in that view as well as checkout the branch directly from VSCode. This familiar environment gives you all the benefits of GitLab MRs - CI/CD, security scanning, approval workflows - without having to leave your own development environment.
But what if you're not at your development box? Or you don't have this particular library or project installed and running locally? Well there's a great solution for that - Gitpod - and it also integrates directly with GitLab. Gitpod allows you to have a working, containerized development environment in seconds. And now with GitLab 14.2, you can launch a Gitpod workspace directly from the GitLab merge request. That means with one button in GitLab you can go from a static code review into a running application with all of the proposed changes.
2) Code quality notices built into the MR diff
GitLab already brings code quality, security, performance, and other metrics directly into the merge request. But in GitLab 13.12, we also added the ability to see code quality notices directly in the MR diff. This means that changes to code quality are presented right next to the offending code, making it quick and easy for reviewers to make suggestions about how to keep code quality top notch while shipping changes.
3) File-by-file reviews
Sometimes with changes it is nice to use the file explorer view and be able to see changes across multiple files. Other times you might want to do a thorough pass on every file to ensure you didn't miss anything. Toggling between seeing all of the changed files and one file at a time is a small but valuable feature that makes code reviews easier.
4) Check off a file as reviewed
Speaking of small but powerful features, one of my favorite features is something many would consider incredibly small. But to that I would say - there are no small features, only small merge requests 😄!
[How to get the most out of your DevOps platform]
The ability to check off files as reviewed has become a natural part of my code review workflow - even when the code I'm reviewing might be code I wrote myself! It allows me to focus more of my review time on the biggest impact changes, ignoring smaller changes or ones that don't directly impact the biggest concerns in a review. And in every review session I use it to make sure I've ACTUALLY reviewed every file...not that any reviewer would ever leave one out 😉.
5) Reviewers vs. Assignee
The last improvement to code review in our DevOps Platform is the addition of "reviewers" as an option in a merge request, alongside the existing choice of "assignee." This can help speed up code reviews by ensuring all team members who have to sign off on a merge request are informed and consulted while also making sure there is a clear responsibility on who will take the next action on a merge request, or be the one to actually click the "merge when pipeline succeeds" button.
We hope your teams will try these new and improved DevOps Platform code review features - and we're not done yet. We'll be shipping improvements and updates to the code review process all of the time. And because everyone can contribute you can add your own ideas and suggestions into our DevOps Platform to make code reviews less painful and more effective.
