BT

Book Review: Learning Gerrit Code Review

Posted by Alex Blewitt on Oct 16, 2013 |

Luca Milanesio's "Learning Gerrit Code Review" is the definitive guide for getting started with Gerrit, both as a user and as an administrator. Gerrit is the review tool that is used by open source projects such as Android and Eclipse for performing source code reviews.

Gerrit grew out of a re-implementation of Mondrian and then Rietveld, but based on a Java runtime instead of a Python one. Its aim is to provide a code review tool that can guard a repository's main branch with human and automated reviews.

Luca covers the benefits and the roles in the first chapter of the book, expanding on the key reasons why code review is of benefit; from code style to shared knowledge and early feedback of test failures as an integral part of the review cycle.

Setting up your own Gerrit server is covered in the next three chapters, from the initial software requirements and setup of database through to user authentication and access methods. A comparison of SSH versus HTTP is presented along with the differences that occur between them. The following three chapters discuss configuration changes, including the global project settings, permissions for individual references, and the different types of submit rules and their effect.

The appendices list some useful information relating to integrating Gerrit with GitHub, with build tools such as Jenkins and some background on Git for those who are not familiar in detail with how the repositories are stored on disk. Given Gerrit's key integration with Jenkins as a build system it is perhaps a little surprising that the Jenkins integration was delegated to an appendix, but it is a welcome addition to the book as a whole.

This book will be useful for those who have decided to implement a Gerrit based workflow, but who have not had the experience of installing or configuring it. There are plenty of examples of running and configuring the process on a Unix system; it is possible to run Gerrit on Windows but the only nod the book gives is the ability to integrate with Microsoft's Active Directory as a user/group source.

For those who are interested in experimenting with Gerrit without the need to configure it, Luca's company GerritForge hosts a review site GerritHub.io, which provides a mechanism to integrate with GitHub's pull requests and provide a review.

InfoQ spoke with Luca Milanesio about his book "Learning Gerrit Code Review":

InfoQ: How long have you been involved with Gerrit? How did you get involved?

Luca: Gerrit captured my interest in 2010, whilst I was driving a migration from Subversion to Git for Vodafone Group in the UK and Germany. I saw many gaps to fill in order to support Git in the Enterprise and started to invest on the platform. We launched GitEnterprise.com in early 2011 but we saw as well a very interesting future in Gerrit, which was not only a well tested solution, thanks to its adoption in the Android OS project, but also a very promising OpenSource project. In the autumn of 2011 we launched the first Enterprise integration of Gerrit with CollabNet TeamForge, which inspired the new name of our Company. In mid-2012 we stopped the development of GitEnterprise to dedicate our entire efforts in contributing to Gerrit Code Review OpenSource project.

InfoQ: What are the main advantages of using Gerrit in a development workflow?

Luca: From my experience the most important aspect of Gerrit is social collaboration around collective code ownership: people are feeling more engaged in looking at the code and express their opinions ! This provides immediate and long-term advantages to Team and Project health. The first visible positive effect is the reduction on the number of broken builds. Even if it may seem small at first sight, it is a substantial benefit for reducing the wasted team's time in fetching a  broken change or fixing the Continuous Integration build because of a faulty patch. A mid-term benefit come because of the extended time reading the code that generates the spreading out the knowledge of the project across the team. Over time people become more aware of the code structure and then will be more precise and effective when developing new features or during maintenance. As a longer-term benefit the team will naturally uniform and improve its coding style and willing to collaborate and extend any part of the project. Comments are often about opinions on how the same algorithm could be implemented with a more concise and maintainable code. People will then spend less time in rewriting and more on extending a much more uniform and clear code-base.

InfoQ: How does Gerrit compare with GitHub style branch reviews/pull requests?

Luca: There is a substantial difference between GitHub Pull Requests and Gerrit Code Review. GitHub is my opinion is more suitable for a "one-man band's project" where often there is one project maintainer and many external contributors that would like to merge their own "version" of the code-base. In GitHub you have to fork and create your own version of the project if you want to provide any contribution. Additionally the pull request is not regulated by a common set of project rules and so it may create confusion and noise when a project gets bigger. Gerrit is designed for the purpose of getting people working together on a project not for forking it into multiple child-projects. Having lots of people on a Project such as the Android OS development requires more organisation, cooperation and rules on how the promotion of changes works. Those rules can be defined on a per-Project basis and define the "democracy" of the Team for scoring and approving changes. From a simplicity point of view, looking at the number of steps required to contribute to a Project, Gerrit is more straightforward compared to GitHub:

- GitHub requires:

  1. fork the project
  2. clone the project
  3. create commit
  4. push to the forked project and
  5. create pull request

- Gerrit only needs:

  1. clone the project
  2. create commit,
  3. push for review

From a user-experience perspective, it is clear that Gerrit has been written for developers by developers: the current user-experience is based on GWT and is neither fancy nor stylish as the GitHub one. The positive side is the ability to skin and customise Gerrit with CSS and plugins which make it more suitable for large Enterprises that need to integrate the tool with their ecosystem: the look and feel needs then to be aligned with the Company brand guidelines rather than with GitHub.

InfoQ: Who is adopting Gerrit? Who is involved in the development of the project?

Luca: Gerrit is the de-facto standard for large enterprises, starting from Telcos and Mobile and MicroChip Technology corporations such as Motorola, SONY Mobile, Intel and Qualcomm up to large Software Factories as SAP and HP and more recently even global banks. Gerrit was initially founded by Shawn Pearce (Google) as tool for the Android OS Development, because the internal version control used at Google was not suitable for external contributors. Subsequently the companies cooperating with the development of the Android ecosystem, as Qualcomm IC and SONY Mobile, started to contribute to the Gerrit development for putting the enhancements made locally to a common factor into the OpenSource Community.  Significant support subsequently came from SAP and then other non-Android focused companies such as Spotify. Gerrit has now over 80 contributors coming even from other OpenSource initiatives, thanks to its adoption in important projects such as Eclipse, Wikipedia, LibreOffice and Openstack.

InfoQ: What made you decide to write a book on Gerrit?

Luca: After working for more than 2 years on the project I understood the potential and value available in the tool but not leveraged by most of the people looking at it from the outside. Gerrit documentation has always been very comprehensive but too technical for a novice user. This has given the false perception that "Gerrit is cool but hard to install and use". I wanted to demystify the myth and demonstrate how you can start from zero Gerrit knowledge and get up-and-running after an easy weekend read. Being forced to stay under 150 pages was definitely a challenge, as a red-brick of 500 pages would have been a much simpler exercise! From the early feedback I got so far it seems that the goal of the book has been achieved. I am hoping that the book will increase the popularity of Gerrit and encourage people to start using and even contributing to it.

InfoQ: Why did you create GerritForge? Who is involved with it?

Luca: We changed our company name from LMIT to GerritForge in 2011, when it was clear that the future of the Agile ALM (our initial company business) was definitely driven by Code Review and Continuous Deployment: we invested in Gerrit development and services and it was then natural to reflect that focus and mission in the name of the company. In GerritForge there was the confluence and experience of LMIT Ltd and Louis Urban Ltd two UK-based consulting companies focused on Software Development and consultancy on Agile.

InfoQ: How did the London Gerrit Hackathon come together; was it a success?

Luca: The proposal of a Gerrit Hackathon came out in 2012, driven by the European Gerrit Contributors coming from Germany, Sweden and UK. Offer came with good appreciation by both US and far-East based members of the Gerrit Project. Google as well was glad to show with facts that Gerrit is not a "private business" for Android but a healthy cooperative world-wide OpenSource platform, opened for anyone's innovation. I think this is the main benefit overall of a platform such as Gerrit compared to other free popular but closed-source initiatives.

InfoQ: When will the next hackathon be?

Luca: Next Hackathon and Gerrit User Conference will be early Spring 2014, most probably at Google in Mountain View CA. Additionally there is an offer for organising the first Hackathon in Tokio – Japan hosted by SONY Mobile. According to Indeed.com job trends Gerrit is momentum is coming and I am sure that the number of participants of the next conferences will soar significantly in 2014 and beyond. The introduction of plugins, initially proposed by GerritForge in 2011 and now driven by the community, has increased the ability to integrate Gerrit into the Continuous Deployment ecosystem and into the entire ALM: I am convinced this will generally improve the way we work and cooperate around the Agile development lifecycle!

Disclaimer: Learning Gerrit Code Review is published by Packt publishing, which is the publisher of Alex Blewitt's Eclipse Plug-in development book.

About the Book Author

Luca Milanesio is the Director and cofounder of GerritForge, the leading Git and Gerrit competence center for the enterprise. His background includes over 20 years of experience in development management, software configuration management, and software development lifecycle in large enterprises worldwide. Luca Milanesio is the author of Git Patterns and Anti-Patterns, an essential guide for scaling Git to the enterprise with 16 patterns and anti-patterns, including Hybrid SCM, Git champions, blessed repository, per-feature topic branches, and ALM integration.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT