• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Git and Gerrit Code Review - Tech Talk - 2010_09_23
 

Git and Gerrit Code Review - Tech Talk - 2010_09_23

on

  • 4,971 views

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)

Statistics

Views

Total Views
4,971
Views on SlideShare
4,967
Embed Views
4

Actions

Likes
3
Downloads
118
Comments
0

2 Embeds 4

https://sigmadesigns-swmanagement.pbworks.com 3
http://www.scoop.it 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Git and Gerrit Code Review - Tech Talk - 2010_09_23 Git and Gerrit Code Review - Tech Talk - 2010_09_23 Presentation Transcript

    • 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
    • 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
    • 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
    • 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
    • Review - how does it Linux ?
      Collected from http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php
      Code Review | © 2010 by M. Sohn
    • 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
    • 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
    • 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
    • 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
    • © SAP 2009 | 10
      Code Review on Mailing List
      Code Review | © 2010 by M. Sohn
    • 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
    • The targetisalwaysthemainlinekernel
      Maintainer: Linus Torvalds
      2-3 month release cycle
      Release cycle
      © SAP 2009 | 12
      Trees
      Code Review | © 2010 by M. Sohn
    • Trees
      Patches travel through trees
      Code Review | © 2010 by M. Sohn
    • 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 (gitbisect)
      • Tools for restructuring branches w/ specific commits
      Code Review | © 2010 by M. Sohn
    • Review - how does it Eclipse ?
      Code Review | © 2010 by M. Sohn
    • 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
    • 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
    • Code Review in Bugzilla
      Code Review | © 2010 by M. Sohn
    • 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
      Code Review | © 2010 by M. Sohn
    • 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
    • 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
    • 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
    • Review - How does it look with Gerrit ?
      Code Review | © 2010 by M. Sohn
    • Gerrit Code Review
      Gerritis a Code Review system based on JGit
      • http://code.google.com/p/gerrit/
      • Also serves as a gitserver
      • adding access control and workflow
      • Used by
      • Androidhttps://review.source.android.com/
      • JGit, EGithttp://egit.eclipse.org/r/
      • Google, SAP, …
      • Eclipse wants to use it …
      Code Review | © 2010 by M. Sohn
    • History GerritCode Review
      Gerrit = 4th Generation code review @ Google
      Google started code review with a Linux like review process
      • patch based
      • tooling based on Perforce CLI
      Code Review | © 2010 by M. Sohn
    • 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
      Code Review | © 2010 by M. Sohn
    • Gerrit – Extreme Branching
      Code Review | © 2010 by M. Sohn
    • 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
    • Gerrit – Rebase
      Code Review | © 2010 by M. Sohn
    • Gerrit – Linear History (optional)
      Code Review | © 2010 by M. Sohn
    • Gerrit - Workflow
      Code Review | © 2010 by M. Sohn
    • Gerrit
      http://egit.eclipse.org/r/ - change,825
      Code Review | © 2010 by M. Sohn
    • 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
    • Gerrit – Lifecycle of a Change
      • create local topic branch
      • commit change
      • push it for review
      • review
      • automated verification
      topic
      master
      1
      a
      Code Review | © 2010 by M. Sohn
    • Gerrit – Lifecycle of a Change
      • create local topic branch
      • commit change
      • push it for review
      • review
      • automated verification
      topic
      master
      1
      a
      master
      topic
      • refine based on review
      • push new patchsets until review votes ok
      c
      3
      b
      2
      a
      1
      Code Review | © 2010 by M. Sohn
    • Gerrit – Lifecycle of a Change
      • create local topic branch
      • commit change
      • push it for review
      • review
      • automated verification
      master
      topic
      master
      d
      topic
      1
      a
      c
      3
      b
      2
      master
      topic
      • refine based on review
      • push new patchsets until review votes ok
      a
      c
      1
      3
      b
      • Submit may lead to server-side merge
      • or merge / rebase before push
      2
      a
      1
      Code Review | © 2010 by M. Sohn
    • 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
    • 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
    • No Free Lunch ? -- DEMO
      Code Review | © 2010 by M. Sohn
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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