Git and Gerrit Code Review - Tech Talk - 2010_09_23

  • 4,502 views
Uploaded on

Deutsche Telekom TechTalk Darmstadt Sept 23 2010 - Code Review with Gerrit, EGit and Git (Matthias Sohn)

Deutsche Telekom TechTalk Darmstadt Sept 23 2010 - Code Review with Gerrit, EGit and Git (Matthias Sohn)

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,502
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
124
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Code Review
    using
    Gerrit, EGit and Git
    http://code.google.com/p/gerrit
    http://eclipse.org/egit
    +
    =
    Matthias Sohn (SAP)
    matthias.sohn@sap.com
    Twitter: @masohn
  • 2. Overview
    Hudson, Mylynintegration
    Tools
    any VCS,change
    management, audit tools
    Gerrit
    EGit, JGit
    CVS, SVN, bugzilla
    mailing lists
    mailing lists
    massive peer review
    review contributions
    review critical areas
    Interaction
    bazaar
    cathedral
    technical quality
    over all
    protect IP of member companies
    classical QA, governance, regulations
    Motivation
    Code Review | © 2010 by M. Sohn
  • 3. Peer Code Review – What is it ?
    Guido van Rossum [1]
    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
    [1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf
    Code Review | © 2010 by M. Sohn
  • 4. Code Review – Benefits
    Guido van Rossum [1]
    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
    [1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf
    Code Review | © 2010 by M. Sohn
  • 5. Review - how does it Linux ?
    Collected from http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php
    Code Review | © 2010 by M. Sohn
  • 6. Roles
    Contributors
    Proposechanges
    Review changes(all changesarereviewed)
    Test, ...
    Maintainers
    Benevolent dictator
    OneMaintainer per subsystem
    Lieutenant hierarchy
    Final decision on inclusionof a change
    Code Review | © 2010 by M. Sohn
  • 7. Guiding Principles
    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 forchanges
    Code Review | © 2010 by M. Sohn
  • 8. 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
    Code Review | © 2010 by M. Sohn
  • 9. 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
    Code Review | © 2010 by M. Sohn
  • 10. © SAP 2009 | 10
    Code Review on Mailing List
    Code Review | © 2010 by M. Sohn
  • 11. Patch Lifecycle
    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.
    Code Review | © 2010 by M. Sohn
  • 12. The targetisalwaysthemainlinekernel
    Maintainer: Linus Torvalds
    2-3 month release cycle
    Release cycle
    © SAP 2009 | 12
    Trees
    Code Review | © 2010 by M. Sohn
  • 13. Trees
    Patches travel through trees
    Code Review | © 2010 by M. Sohn
  • 14. Git
    … a distributed revision control system built by the Linux project to automate patch workflow
    Distributed means no central repository
    • No central authority!
    • 15. Easy offline usage
    • 16. Easy to fork a project
    • 17. Protected against manipulation by cryptographic hashes
    Really good at merging
    • Coordination only needed "after the fact”
    • 18. Easier to rejoin (or refresh) forked projects
    Structured around commits (i.e. patches)
    • Integrates with email channel
    • 19. Tools for identifying problem commits (gitbisect)
    • 20. Tools for restructuring branches w/ specific commits
    Code Review | © 2010 by M. Sohn
  • 21. Review - how does it Eclipse ?
    Code Review | © 2010 by M. Sohn
  • 22. The Eclipse Way
    Copied from Pat Huff (IBM)http://www.eclipsecon.org/2008/sub/attachments/Managing_Eclipse_Adoption_in_the_Enterprise.pdf
    Code Review | © 2010 by M. Sohn
  • 23. Eclipse - Roles
    Committer
    Formally elected
    Can commit own changes without review
    Contributor
    Small changes
    reviewed by committers
    Bigger changes
    also formal IP review by legal team in separate protected Bugzilla
    Review Tool
    patches attached to bug in Bugzilla
    comments in Bugzilla
    Code Review | © 2010 by M. Sohn
  • 24. Code Review in Bugzilla
    Code Review | © 2010 by M. Sohn
  • 25. Eclipse – Review Process
    Contributors
    • create patch using CVS, SVN, Git
    • 26. attach patch to bug in Bugzilla
    Committers
    • do code and IP review
    • 27. comment, vote in Bugzilla
    • 28. create CQ for changes needing IP review
    • 29. commit accepted changes
    IP Team
    • does IP review bigger changes from contributors
    Code Review | © 2010 by M. Sohn
  • 30. Eclipse – Review Process
    Review not done for all changes
    Review tedious for contributors (and also for committers mentoring contributors)
    Code Review | © 2010 by M. Sohn
  • 31. Git at Eclipse (since 2009)
    Eclipse defined a roadmap to move to Git
    EGitis 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.
    Code Review | © 2010 by M. Sohn
  • 32. History JGit/EGit
    2005    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/2010Released 0.9 (Helios SR1)
                Merge, Synchronize View, .gitignore
    Planned 12/2010 0.10 3/2011 0.11 6/2011 1.0 (Indigo)
    Git at Eclipse | © 2010 by M. Sohn
  • 33. Review - How does it look with Gerrit ?
    Code Review | © 2010 by M. Sohn
  • 34. Gerrit Code Review
    Gerritis a Code Review system based on JGit
    • http://code.google.com/p/gerrit/
    • 35. Also serves as a gitserver
    • 36. adding access control and workflow
    • 37. Used by
    • 38. Androidhttps://review.source.android.com/
    • 39. JGit, EGithttp://egit.eclipse.org/r/
    • 40. Google, SAP, …
    • 41. Eclipse wants to use it …
    Code Review | © 2010 by M. Sohn
  • 42. History GerritCode Review
    Gerrit = 4th Generation code review @ Google
    Google started code review with a Linux like review process
    • patch based
    • 43. tooling based on Perforce CLI
    Code Review | © 2010 by M. Sohn
  • 44. Google - Web based code review tools
    Mondrian(Guido van Rossum)
    • based on Perforce, Google infrastructure
    • 45. Google proprietary
    Rietvield(Guido van Rossum)
    • based on Subversion
    • 46. Open Source hosted on GoogleApp Engine
    Gerrit(Shawn Pearce)
    • started as a fork of Rietvield
    • 47. based on JGit and GWT
    • 48. Open Source (Android)
    • 49. Apache 2 license
    Code Review | © 2010 by M. Sohn
  • 50. Gerrit – Extreme Branching
    Code Review | © 2010 by M. Sohn
  • 51. One Branch per Feature
    Master branch contains only reviewed and approved changes
    master moves from good to better state after each (approved) change
    Each feature branch is based on the Master branch
    stable starting point
    coupling only with approved changes when developing new code
    A change can really be abandoned because
    no other change can depend on a not yet approved change
    gerrit will automatically reject a successor change of an abandoned change
    Code Review | © 2010 by M. Sohn
  • 52. Gerrit – Rebase
    Code Review | © 2010 by M. Sohn
  • 53. Gerrit – Linear History (optional)
    Code Review | © 2010 by M. Sohn
  • 54. Gerrit - Workflow
    Code Review | © 2010 by M. Sohn
  • 55. Gerrit
    http://egit.eclipse.org/r/ - change,825
    Code Review | © 2010 by M. Sohn
  • 56. 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
    Code Review | © 2010 by M. Sohn
  • 57. Gerrit – Lifecycle of a Change
    • create local topic branch
    • 58. commit change
    • 59. push it for review
    • 60. review
    • 61. automated verification
    topic
    master
    1
    a
    Code Review | © 2010 by M. Sohn
  • 62. Gerrit – Lifecycle of a Change
    • create local topic branch
    • 63. commit change
    • 64. push it for review
    • 65. review
    • 66. automated verification
    topic
    master
    1
    a
    master
    topic
    • refine based on review
    • 67. push new patchsets until review votes ok
    c
    3
    b
    2
    a
    1
    Code Review | © 2010 by M. Sohn
  • 68. Gerrit – Lifecycle of a Change
    • create local topic branch
    • 69. commit change
    • 70. push it for review
    • 71. review
    • 72. automated verification
    master
    topic
    master
    d
    topic
    1
    a
    c
    3
    b
    2
    master
    topic
    • refine based on review
    • 73. push new patchsets until review votes ok
    a
    c
    1
    3
    b
    • Submit may lead to server-side merge
    • 74. or merge / rebase before push
    2
    a
    1
    Code Review | © 2010 by M. Sohn
  • 75. 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 | © 2010 by M. Sohn
  • 76. 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
    Code Review | © 2010 by M. Sohn
  • 77. No Free Lunch ? -- DEMO
    Code Review | © 2010 by M. Sohn
  • 78. Conclusion
    Code Review rocks !
    Gerrit enables a nice code review workflow
    DVCS like Git are powerful
    Git supports convenient branching and merging
    Gitis very fast and scales well
    Code Review | © 2010 by M. Sohn
  • 79. Gerrit Code Review
    Gerrit developed at http://code.google.com/p/gerrit
    https://review.source.android.com/Gerrit for Android projects (also Gerrit)
    Code Review | © 2010 by M. Sohn
  • 80. Git at Eclipse
    EGit/JGit developed at http://egit.eclipse.org
    http://git.eclipse.org/hosts live Eclipse Git repos
    Virgo, Mylyn Review, ScalaModules, SWTBot …
    http://dev.eclipse.org/git/index.html git mirrors for CVS
    Read-only copies kept up-to-date
    Can clone with git:// or http://
    Code Review | © 2010 by M. Sohn
  • 81. 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 Google
    http://www.youtube.com/watch?v=4XpnKHJAok8
    Read the Pro Git book - http://progit.org/book/
    Code Review | © 2010 by M. Sohn
  • 82. Gerrit Code Review - Outlook
    Upcoming proposal for MylynGerrit Connector
    Port from SQL DB to Cassandra
    Store review comments as git notes for offline review
    Support for change dependencies across repositories

    Code Review | © 2010 by M. Sohn
  • 83. 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
    Features EGit 0.9
    * planned for next release, supported, partial, missing, irrelevant for EGit