git and gerrit code review - tech talk - 2010_09_23

Code Review using

Gerrit, EGit and Githttp://code.google.com/p/gerrit

http://eclipse.org/egit

Matthias Sohn (SAP)[email protected]

Twitter: @masohn

+ =

http://code.google.com/p/gerrit



http://eclipse.org/egit

mailto:[email protected]

Overview

Code Review | © 2010 by M. Sohn

Mot

ivat

ion

Inte

ract

ion

Tool

s

mailing lists

CVS, SVN, bugzilla mailing lists

any VCS,change

management, audit tools

Gerrit

Hudson, Mylynintegration

EGit, JGit

bazaar cathedral

technical qualityover all

protect IP of member

companies

classical QA, governance, regulations

massive peer review review contributions review critical areas

Peer Code Review – What is it ?

When one developer writes code, another developer is asked to review that code

A careful line-by-line critique

Happens in a non-threatening context

Goal is cooperation, not fault-finding

Often an integral part of coding process

Debugging someone else's broken code– Involuntary code review: Not so good; emotions may flare


Guido van Rossum [1]

[1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf

http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf







Code Review – Benefits

Four eyes catch more bugs Catch bugs early to save hours of debugging

Enforce coding standards Keep overall readability & code quality high

Mentoring of new developers Learn from mistakes without breaking stuff

Establish trust relationships Prepare for more delegation

Good alternative to pair programming asynchronous and across locations


Guido van Rossum [1]

[1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf








Review - how does it

Linux ?


Collected from http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php

http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php

Contributors– Propose changes– Review changes (all changes are reviewed)– Test, ...

Maintainers– Benevolent dictator– One Maintainer per subsystem– Lieutenant hierarchy– Final decision on inclusion of a change

Roles


Technical quality over all

Code quality outweighs– Company plans– User desires– Existing practice– Developer status

Long-term view– Kernel developers expect to be maintaining the code 5-10 years

Massive peer review– No code is perfect– it can always be improved– heed requests for changes

Guiding Principles


No ownership of code– Even code you wrote

No regressions– ...even to fix other problems– “So we don't fix bugs by introducing new problems. That way

lies madness, and nobody ever knows if you actually make any real progress at all. Is it two steps forwards, one step back, or one step forward and two steps back?”-- Linus Torvalds

No inherent right to inclusion– Changes require justification– Other solutions may win out

Guiding Principles


Fundamental unit of work is the patch...

• Identifies your exact set of changes• Encapsulates changes to all modified files• Resilient across changes to underlying files

© SAP 2009 | 9

Patches


© SAP 2009 | 10

Code Review on Mailing List


DesignThis is where the real requirements for the patch -- and the way those requirements will be met -- are laid out.

Early review Patches are posted to the relevant mailing list, and developers on that list reply with any comments they may have.

Wider review When the patch is getting close to ready for mainline inclusion, it will be accepted by a relevant subsystem maintainer -- though this acceptance is not a guarantee that the patch will make it all the way to the mainline.

Merging into the mainline Eventually, a successful patch will be merged into the mainline repository. More comments and/or problems may surface at this time

Stable release The number of users potentially affected by the patch is now large, so, once again, new problems may arise.

Long-term maintenance The original developer should continue to take responsibility for the code if it is to remain useful in the longer term.

Patch Lifecycle


The target is always the mainline kernel– Maintainer: Linus Torvalds– 2-3 month release cycle

Release cycle

© SAP 2009 | 12

Trees


TreesPatches travel through trees


Git… a distributed revision control system built by the Linux project to automate patch workflow

Distributed means no central repository• No central authority!• Easy offline usage• Easy to fork a project• Protected against manipulation by cryptographic hashes

Really good at merging• Coordination only needed "after the fact”• Easier to rejoin (or refresh) forked projects

Structured around commits (i.e. patches)• Integrates with email channel• Tools for identifying problem commits (git bisect)• Tools for restructuring branches w/ specific commits


Review - how does it

Eclipse ?


The Eclipse Way


Copied from Pat Huff (IBM)http://www.eclipsecon.org/2008/sub/attachments/Managing_Eclipse_Adoption_in_the_Enterprise.pdf

http://www.eclipsecon.org/2008/sub/attachments/Managing_Eclipse_Adoption_in_the_Enterprise.pdf





Eclipse - Roles

CommitterFormally electedCan commit own changes without review

ContributorSmall changes

reviewed by committersBigger changes

also formal IP review by legal teamin separate protected Bugzilla

Review Toolpatches attached to bug in Bugzillacomments in Bugzilla


Code Review in Bugzilla


Eclipse – Review Process

Contributors • create patch using CVS, SVN, Git• attach patch to bug in Bugzilla

Committers • do code and IP review• comment, vote in Bugzilla• create CQ for changes needing IP review• commit accepted changes

IP Team• does IP review bigger changes from contributors


Eclipse – Review Process

Review not done for all changes

Review tedious for contributors (and also for committers mentoring contributors)


Git at Eclipse (since 2009)

Eclipse defined a roadmap to move to Git

EGit is an Eclipse Team provider for Git http://www.eclipse.org/egit/

JGit is a lightweight Java library implementing Git http://www.eclipse.org/jgit/

The goal is to build an Eclipse community around Git. EGit/JGit are still beta and we want to establish a feedback loop to improve the tooling.


http://www.eclipse.org/egit/

http://www.eclipse.org/jgit/

Git at Eclipse | © 2010 by M. Sohn

History JGit/EGit2005 Linus Torvalds starts Git

2006 Shawn Pearce starts JGit

2009 Eclipse decides for Git Roadmap JGit/EGit move to eclipse.org SAP joins

3/2010 Released 0.7 (first release at Eclipse) Diff/Merge Algorithms, Automatic IP Logs

6/2010 Released 0.8 (Helios) Usability Improvements, Git Repositories View, Tagging

9/2010 Released 0.9 (Helios SR1) Merge, Synchronize View, .gitignore

Planned 12/2010 0.10 3/2011 0.11 6/2011 1.0 (Indigo)

Review - How does it look with

Gerrit ?


Gerrit Code Review

Gerrit is a Code Review system based on JGit http://code.google.com/p/gerrit/

Also serves as a git server adding access control and workflow

Used by • Android https://review.source.android.com/• JGit, EGit http://egit.eclipse.org/r/• Google, SAP, …

Eclipse wants to use it …


http://code.google.com/p/gerrit/

https://review.source.android.com/



http://egit.eclipse.org/r/



History Gerrit Code Review

Gerrit = 4th Generation code review @ Google

Google started code review with a Linux like review process

• patch based• tooling based on Perforce CLI


Google - Web based code review tools

Mondrian (Guido van Rossum)• based on Perforce, Google infrastructure• Google proprietary

Rietvield (Guido van Rossum)• based on Subversion• Open Source hosted on GoogleApp Engine

Gerrit (Shawn Pearce)• started as a fork of Rietvield• based on JGit and GWT• Open Source (Android)• Apache 2 license


http://video.google.com/videoplay?docid=-8502904076440714866

http://code.google.com/p/rietveld/



Gerrit – Extreme Branching

One Branch per Feature

Master branch contains only reviewed and approved changesmaster moves from good to better state after each (approved)

change

Each feature branch is based on the Master branchstable starting pointcoupling only with approved changes when developing new

code

A change can really be abandoned becauseno other change can depend on a not yet approved changegerrit will automatically reject a successor change of an

abandoned change



Gerrit – Rebase


Gerrit – Linear History (optional)

Gerrit - Workflow


Gerrit - Workflow Every change is reviewed

- Authors can invite reviewers- Complex changes reviewed by many

Look at the change- Comment on how to improve it- Discuss in context of the change

Download the change- test it- improve it

Discussion usually leads to new improved change


Gerrit – Lifecycle of a Change

a

master

topic

1

• create local topic branch

• commit change• push it for review• review• automated

verification



c

b

a1

2

mastertopic

3

a

master

topic

1



verification

• refine based on review

• push new patchsets until review votes ok



c

b

a1

2

mastertopic

3

a

master

topic

1



verification

• refine based on review

• push new patchsets until review votes ok

c

b

a1

2

master

topic

3

d

• Submit may lead to server-side merge

• or merge / rebase before push


Code Review – Our Experience

Review all changes!

Review takes time (1 day … weeks)

Implies parallel workflow

Every team member should do reviews regularly

Authors have to wait for the review to happen

Git & Gerrit help a lot here


Code Review – Tips

Small changes are much easier to review

A change should logically do one thing (not many)

No change shall break build or tests

Split big changes into series of digestible changes (patch series)- These changes depend on each other- Last change should switch the new feature on

Commit message should explain Why - The What should be obvious from the code change


No Free Lunch ? -- DEMO


Conclusion

Code Review rocks !

Gerrit enables a nice code review workflow

DVCS like Git are powerful

Git supports convenient branching and merging

Git is very fast and scales well


Gerrit Code Review

Gerrit developed at http://code.google.com/p/gerrit

https://review.source.android.com/Gerrit for Android projects (also Gerrit)


http://egit.eclipse.org/


Git at Eclipse

EGit/JGit developed at http://egit.eclipse.org

http://git.eclipse.org/ hosts live Eclipse Git reposVirgo, Mylyn Review, ScalaModules, SWTBot …

http://dev.eclipse.org/git/index.html git mirrors for CVSRead-only copies kept up-to-dateCan clone with git:// or http://



http://git.eclipse.org/

http://dev.eclipse.org/git/index.html

Git Resources

Ask questions on the EGit forum or egit-dev/jgit-dev lists

http://git-scm.com/documentation is your friend

If you want comedy, watch Linus' talk at Googlehttp://www.youtube.com/watch?v=4XpnKHJAok8

Read the Pro Git book - http://progit.org/book/


http://www.eclipse.org/forums/eclipse.egit

http://dev.eclipse.org/mailman/listinfo/egit-dev

http://dev.eclipse.org/mailman/listinfo/egit-dev

http://dev.eclipse.org/mailman/listinfo/jgit-dev

http://dev.eclipse.org/mailman/listinfo/jgit-dev

http://git-scm.com/documentation

Gerrit Code Review - Outlook

Upcoming proposal for Mylyn Gerrit Connector

Port from SQL DB to Cassandra

Store review comments as git notes for offline review

Support for change dependencies across repositories

…


Features EGit 0.9

git-add git-format-patch git-shortlog git-relink git-rev-parse

git-am git-gc git-show git-remote git-show-branch

git-archive git-grep git-stash git-repack git-verify-tag

git-bisect git-init git-status git-replace git-whatchanged

git-branch git-log git-submodule git-annotate

git-bundle * git-merge * git-tag * git-blame

git-checkout git-mv git-config git-cherry .gitignore

* git-cherry-pick git-notes git-fast-export git-count-objects git daemon

git-clean * git-pull git-fast-import git-difftool * HTTP support

git-clone git-push git-filter-branch git-fsck * Mylyn integration

git-commit * git-rebase git-mergetool git-get-tar-commit-id

* Staging View

git-describe git-reset git-pack-refs git-help * Synchronize View

git-diff git-revert git-prune git-merge-tree History View

git-fetch git-rm git-reflog git-rerere Repositories View

* planned for next release, supported, partial, missing, irrelevant for EGit

git and gerrit code review - tech talk - 2010_09_23

Technology