Code review with Gerrit
Emmanuel Jeanvoine, S´ebastien Badia
2013/06/12
1 / 36 Agenda
1 Code review
2 Gerrit
3 Social and technical organization
4 Gerrit and continuous integration
5 Conclusion
2 / 36 Agenda
1 Code review
2 Gerrit
3 Social and technical organization
4 Gerrit and continuous integration
5 Conclusion
3 / 36 Code review defined by Wikipedia
What is it? Code review is systematic examination of computer source code Why? It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills
4 / 36 Kind of software testing
• Static testing
I does not require executing program like dynamic testing • Can be omitted in a software development process and in practice is • Usually, strongly improves the software quality • Some statistics1
I Typical code review rates are about 150 lines of code per hour
I About 65% defect removal
I Up to 75% of code review defects affect software evolution rather than functionality
1http://en.wikipedia.org/wiki/Code_review 5 / 36 Types of code review
• Over-the-shoulder • Email pass-around • Pair programming • Tool-assisted code
6 / 36 Over-the-shoulder review
Easy to implement , Fast to complete , Might work remotely with desktop-sharing ,and conference calls Reviewer led through code at author’s pace / Usually no verification that defects are really /fixed Easy to accidentally skip over a changed file / Impossible to enforce the process / No metrics or process /measurement/improvement
Courtesy of http://www.methodsandtools.com/archive/archive.php?id=66
7 / 36 Email pass-around review
Fairly easy to implement , Works with remote developers , SCM system can initiate reviews ,automatically Easy to involve other people , Does not interrupt reviewers , Usually no verification that defects /are really fixed How do you know when the /review is ”complete?” Impossible to know if reviewers are /just deleting those emails No metrics or process /measurement/improvement
Courtesy of http://www.methodsandtools.com/archive/archive.php?id=66
8 / 36 Pair-programming review
Shown to be effective at finding bugs and ,promoting knowledge-transfer Reviewer is ”up close” to the code so can ,provide detailed review Some developers like it , Some developers don’t like it / Reviewer is ”too close” to the code to /step back and see problems Consumes a lot of up-front time / Doesn’t work with remote developers / No metrics or process /measurement/improvement
Courtesy of http://www.methodsandtools.com/archive/archive.php?id=66
9 / 36 Tool-assisted code review
• Refers to any process where specialized tools are used in all aspects of the review
I collecting files
I transmitting and displaying files
I commentary
I defects • Can refer to
I open-source projects
I commercial software
I home-grown scripts • In any case, this is never free
I you’re either paying for the tool or paying your own folks to understand an existing one/create a new one
I you have to make sure the tool matches your desired workflow
Courtesy of http://www.methodsandtools.com/archive/archive.php?id=66
10 / 36 Agenda
1 Code review
2 Gerrit
3 Social and technical organization
4 Gerrit and continuous integration
5 Conclusion
11 / 36 Gerrit
Gerrit2 • Works on top of GIT • Is open source (Apache v2.0) • Developed by Google for Android • Fork of Rietveld3 (SVN code review) • Used in big projects: LibreOffice, OpenStack, Qt, Mediawiki, ... • Easily customizable, plugins • Active project 2.5.4 released on 2013/05/18
2http://code.google.com/p/gerrit/ 3http://code.google.com/p/rietveld/ 12 / 36 Git vs. Gerrit
Git workflow
Barbie Fetch/Push
Git
Authoritative Repository
Fetch/Push Ken
13 / 36 Git vs. Gerrit
Gerrit workflow
Gerrit
Fetch Fetch Authoritative Repository
Pumbaa Timon Submit
Push Pending Changes Push
Fetch Approve
Reviewer
13 / 36 Gerrit user-side
• Gerrit account creation in 3 steps (login,mail,ssh key) • Differences with GIT:
I Direct push prohibited (branch become HEAD:refs/for/branch) 4 I User ChangeId (hashed in your commit message) • SSH commands5 (ls-project, review, reviewers) • Tools beyond gerrit: 6 I Git-review (patch set lists / project setup / ease submit)
4https://gerrit.wikimedia.org/r/Documentation/user-changeid.html 5https://gerrit.wikimedia.org/r/Documentation/cmd-index.html 6http://www.mediawiki.org/wiki/Gerrit/git-review 14 / 36 Gerrit demo
15 / 36 Gerrit internals (Server-side)
• Requirements
I Java 1.6 (minimum)
I Database (mysql/pgsql/h2)
I A MTA properly configured • Installation very simplistic (CLI assisted) or Puppet module • Firewall needs (must be changed)
I Gerrit commands/SSH port (default: 29418)
I Web access (80 and/or 443), but can be proxified • Authentication: OpenID, LDAP, Apache (htpasswd), Internal • Replication configuration
I By project (with authentication group), ideal for Inria forge.
I Or mirror mode, (all gerrit project are mirrored/replicated).
16 / 36 Integration with an existing project
Authoritative Repository (GForge Inria)
Mirror Gerrit
Fetch Fetch Authoritative Repository
Ingo Alan Submit
Push Pending Changes Push
Fetch Approve
Reviewer
17 / 36 Agenda
1 Code review
2 Gerrit
3 Social and technical organization
4 Gerrit and continuous integration
5 Conclusion
18 / 36 Context: software development in AlGorille
• Distributed systems experimentation: several software projects
I ADT Kadeploy
I Lucas N. (scientific leader) I Emmanuel J. (technical leader and former developer) I Luc S. (developer) I several interns
I ADT Solf`ege
I Lucas N. (scientific leader) I Emmanuel J. (developer and technical leader on some parts) I Luc S. (former developer) I several interns
I Ruby CUTE (Commonly Used Tools for grid Experimentation)
I large part of AlGorille team: Lucas N., Emmanuel J., Luc S., S´ebastien B., Tomasz B. I several interns • It’s hard for project managers to keep an eye on all the developments • It’s a good idea to benefit from former developer’s experience • One year ago we have chosen to try code review
19 / 36 Technical organization 1/2
Implementation • Gerrit server installed and administrated by S´ebastien B. • Kadeploy, Distem, and RubyCUTE repositores are using Gerrit • Everybody can technically perform reviews, in practice Emmanuel J. and Luc S. are the main reviewers • After a commit, Gerrit sends a mail to say that a pending review is available • Only one reviewer is needed to perform a review
20 / 36 Technical organization 2/2
Our rules • As a reviewer
I Do not review your own code
I Try to review quickly after a notification • As a developer
I Try to perform small and documented commits
I Create a local branch per feature/bugfix
I If a commit must not be reviewed right now, inform reviewers with the appropriate Gerrit tag
21 / 36 The real life trilogy – episode 1
Reviewers can be under pressure • Luc S. – Emmanuel J., can you have a look to Gerrit? • Emmanuel J. – Erm, I am very busy right now. I will do it later • Luc S. – Come on, I have promised to provide S´ebastien B. with a new Kadeploy3 RC release in 10 minutes • Emmanuel J. – OK . . . (Grrrr!, 150 LOC to review !!!)
22 / 36 The real life trilogy – episode 2
Using Gerrit is a bit more tricky than using only Git • Luc S. – Emmanuel J., can you have a look to Gerrit? I have 17 pending patchsets • Emmanuel J. – OK, I am in a good mood this morning. After the review, some patch sets are submitted and a few are rejected. Luc S., concerning your patchsets 3, 12, 14, I think they are not corrects because . . . • Luc S. – OK. I am doing this right now. After the modifications, Emmanuel J., that is modified, you can have a look • Emmanuel J. – I am OK with with your modifications but Gerrit does not want to merge the patchsets :-D • Luc S. – Grrrr! I haven’t created every patchsets from separate branches ... S´ebastien B., HELP!!!
23 / 36 The real life trilogy – episode 3
Gossiping should be avoided • Luc S. – Emmanuel J., I have submitted a patchset but do not review/submit it because I have found a bug in it • Emmanuel J. – OK • meanwhile, Lucas N. checks its mails during a practical session break, sees the patch set, reviews it and submits it • Luc S. – Grrrr! Lucas N. has merged the patchset . . .
24 / 36 Agenda
1 Code review
2 Gerrit
3 Social and technical organization
4 Gerrit and continuous integration
5 Conclusion
25 / 36 Human time is expensive
• Verifying that a code is running is really important
I it should be done after every commit
I but asking a human to do it has no value added • Continuous integration service (Jenkins at Inria) can do that for us, this is based on
I a test suite (unit/integration/system tests) that validates the correct behavior
I a Gerrit plugin for Jenkins that triggers build and test suite once a patch set is submitted to Gerrit
26 / 36 Gerrit and CI workflow
Courtesy of http://blogs.collab.net/teamforge/teamforge-git-gerrit-integration-with-jenkins-ci
27 / 36 Jenkins plugin
• Gerrit Trigger: https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger • Requires Git plugin too • Creates an SSH connexion to the Gerrit server from Jenkis and check for new patch sets
28 / 36 Jenkins configuration - 1/2
29 / 36 Jenkins configuration - 2/2
30 / 36 Implementation in our main projects
• No trivial since our projects rely on some low level (software and hardware) parts • Distem: an emulator for distributed systems study
I based on: LXC virtualization, traffic control, cpufreq
I partial test suite (no virtual network, no cpufreq) executed after every Gerrit submitted patch set on CI
I complete test suite executed directly on Grid’5000 every week • Kadeploy: a cluster provisioning tool
I based on: hardware management cards, tftp/dhcp/mysql services
I after some (important) submitted gerrit patch set, a complete test suite is executed on Grid’5000
31 / 36 Agenda
1 Code review
2 Gerrit
3 Social and technical organization
4 Gerrit and continuous integration
5 Conclusion
32 / 36 Why Gerrit?
Why not Gerrit? • Dramatic code quality improvement • Enforcement of common idioms and project standards • Clear workflows and defect traceability for contributions • Encouragement of intra-project collaboration and knowledge sharing • Greater inter-project transparency
33 / 36 Actually there are some pitfalls
• But none of them is insurmountable, in particular with a good discipline
I A branch per commit
I Gerrit Change-ID post-commit Git hook • Having a Git guru in the team is a real value-added when using Gerrit
I At least, having a good Git knowledge is a prerequisite • A significant time is required to adjust your development workflow
34 / 36 Conclusion
• Gerrit, and code review in general
I improves your code, we strongly believe that
I encourages discussions in the team
I helps to keep a global view on several software projects • After almost one year, we will probably not move backwards • For those who are interested in testing Gerrit, we can open accounts and projects on a prototype
35 / 36 Some links
• Code review (Wikipedia) http://en.wikipedia.org/wiki/Code_review • Four ways to practical code review http://www.methodsandtools.com/archive/archive.php?id=66 • Adopting Gerrit http://milesparker.blogspot.fr/2013/01/adopting-gerrit.html • Gerrit with Jenkins: installation and configuration http://dachary.org/?p=1716 • Gerrit tutorial http://www.mediawiki.org/wiki/Gerrit/Tutorial
36 / 36