Why Gerrit is awesome

Since a few months we've been using Gerrit as our code reviewing tool. In this article I will share my experiences with Gerrit. I will tell you why Gerrit is awesome, but also what is not great about it.

What is Gerrit and how does it work?

Gerrit is a web-based code reviewing tool, developed by Google for the development of the Android project. It acts as an intermediate between the developers and the remote Git repository. All commits are submitted to Gerrit, where each commit must be reviewed in order to send it upstream to the remote repository. Each commit must also be verified. In our case, a build is run automatically on Jenkins, our continuous integration system. If Jenkins doesn't find any problems the commit is set to verified. Before we can submit it to the remote repository, it also needs a positive review.
The main Gerrit page looks like this:

In this page you can find all commits that have not yet been submitted to the remote repository. The last two columns indicate if a commit has been verified and if a commit has received a positive code review. Gerrit has a system where you can rate a commit from -2 to +2:

How you implement the code review process is up to you: you can configure rights for which users are allowed to approve commits and if users are allowed to review their own commits, for example.

Why Gerrit is awesome

Most of the reasons why Gerrit is awesome have nothing to do with Gerrit as a tool, but have to do with code reviewing.

Code reviewing is awesome It promotes craftsmanship. Due to the fact that team members know their code will be reviewed, everyone wants to create good code. We've had lots of discussions about what good code is and how we can improve.
Code reviewing fosters the sharing of knowledge in your team Each team member is forced to review code that he or she did not write. If the commit is not clear, the reviewer communicates with the author of the commit to discuss it. Most of the time the discussion leads to improving the commit, which is a learning process for both developers.
Code reviewing is fun If you have a team like mine, you will sometimes find beautiful code. Code with brilliant, simple solutions to complicated problems. Solutions that I couldn't have thought of myself. Finding stuff like that really brightens a day.
Code reviews prevent bad commits No developer creates only good commits. Code reviewing prevents bad commits from other developers to become your problem. It also has the effect that developers think twice before submitting a commit.
View changes and place inline comments This is what Gerrit is good at. You can view changes in an accurate diff and specify how much context around the change you want to see. As reviewer, you can place inline comments, exactly at the spot where you question the code and share them with the author. For the author, this information is invaluable.
Fine grained access and authorisation The code review process is what it is, but you have a fine grained control over what users and groups are allowed to do. Per project you can also override these settings.

What is not great about Gerrit

As with the advantages, most disadvantages of the usage of Gerrit have to do with the process of code reviewing.

It slows down the time-to-market All this reviewing, verifying and resubmitting of commits slows down your time-to-market by at least 5%. You will win time eventually. The main reason for this is that the quality of code will be better. This leads to less bugs, better maintainability and easier adaptability. However, if outside pressure dictates that speed is more important than quality, you should not introduce code reviewing.
Getting all commits upstream is complex Commits are not sent upstream exactly in the same order they were submitted to Gerrit. Combine this with having multiple commits that are dependent on each other or commits with different authors that change the same lines of code and you will understand how you can get into trouble. Sometimes you will even have to rewrite commits of other authors. Git is awesome in the way that it can handle all kinds of these challenges, but you will have to have the skills to tell Git how to do this. To introduce Gerrit succesfully, your developers must have a deep understanding of how a Git works (and it's history) and have at least some experience with an interactive Git rebase.
Who is going to review the code and when This is a recurring question, probably most annoying when your team members are not at work. In Gerrit you can assign a reviewer, who then receives an email, but that's it. While it's a crucial part of an efficient code reviewing process, it's not a part of Gerrit.

As you can see, code reviewing with Gerrit has it's advantages and disadvantages. If you're considering to try it out: be aware. Although Gerrit is awesome, it's not about Gerrit. It's about introducing code reviewing into your process. Once you know how to get that right, you can also master the tool itself. No doubt.