Code Review <br />using<br />Gerrit, EGit and Git<br />http://code.google.com/p/gerrit<br />http://eclipse.org/egit<br />+...
Overview<br />Hudson, Mylynintegration<br />Tools<br />any VCS,change <br />management, audit tools<br />Gerrit<br />EGit,...
Peer Code Review – What is it ?<br />Guido van Rossum [1]<br />When one developer writes code, another developer is asked ...
Code Review – Benefits<br />Guido van Rossum [1]<br />Four eyes catch more bugs<br /><ul><li>Catch bugs early to save hour...
Review - how does it Linux ?<br />Collected from http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php<br...
Roles<br />Contributors<br />Proposechanges<br />Review changes(all changesarereviewed)<br />Test, ...<br />Maintainers<br...
Guiding Principles<br />Technical quality over all<br />Code quality outweighs<br />Company plans<br />User desires<br />E...
Guiding Principles<br />No ownership of code<br />Even code you wrote<br />No regressions<br />...even to fix other proble...
Fundamental unit of work is the patch...<br />Identifies your exact set of changes<br />Encapsulates changes to all modifi...
© SAP 2009  |  10<br />Code Review on Mailing List<br />Code Review | © 2010 by M. Sohn<br />
Patch Lifecycle<br />DesignThis is where the real requirements for the patch -- and the way those requirements will be met...
The targetisalwaysthemainlinekernel<br />Maintainer: Linus Torvalds<br />2-3 month release cycle<br />Release cycle<br />©...
Trees<br />Patches travel through trees<br />Code Review | © 2010 by M. Sohn<br />
Git<br />… a distributed revision control system built by the Linux project to automate patch workflow<br />Distributed me...
Easy offline usage
Easy to fork a project
Protected against manipulation by cryptographic hashes</li></ul>Really good at merging<br /><ul><li>Coordination only need...
Easier to rejoin (or refresh) forked projects</li></ul>Structured around commits (i.e. patches)<br /><ul><li>Integrates wi...
Tools for identifying problem commits (gitbisect)
Tools for restructuring branches w/ specific commits</li></ul>Code Review | © 2010 by M. Sohn<br />
Review - how does it Eclipse ?<br />Code Review | © 2010 by M. Sohn<br />
The Eclipse Way<br />Copied from Pat Huff (IBM)http://www.eclipsecon.org/2008/sub/attachments/Managing_Eclipse_Adoption_in...
Eclipse - Roles<br />Committer<br />	Formally elected<br />Can commit own changes without review<br />Contributor<br />Sma...
Code Review in Bugzilla<br />Code Review | © 2010 by M. Sohn<br />
Eclipse – Review Process<br />Contributors<br /><ul><li>create patch using CVS, SVN, Git
attach patch to bug in Bugzilla</li></ul>Committers<br /><ul><li>do code and IP review
comment, vote in Bugzilla
create CQ for changes needing IP review
commit accepted changes</li></ul>IP Team<br /><ul><li>does IP review bigger changes from contributors</li></ul>Code Review...
Eclipse – Review Process<br />Review not done for all changes<br />Review tedious for contributors (and also for committer...
Git at Eclipse (since 2009)<br />Eclipse defined a roadmap to move to Git<br />EGitis an Eclipse Team provider for Git<br ...
History JGit/EGit<br />2005    Linus Torvalds starts Git<br />2006    Shawn Pearce starts JGit<br />2009    Eclipse decide...
Review - How does it look with Gerrit ?<br />Code Review | © 2010 by M. Sohn<br />
Gerrit Code Review<br />Gerritis a Code Review system based on JGit<br /><ul><li>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 …</li></ul>Code Review | © 2010 by M. Sohn<br />
History GerritCode Review<br />Gerrit = 4th Generation code review @ Google<br />Google started code review with a Linux l...
tooling based on Perforce CLI</li></ul>Code Review | © 2010 by M. Sohn<br />
Google - Web based code review tools<br />Mondrian(Guido van Rossum)<br /><ul><li>based on Perforce, Google infrastructure
Google proprietary</li></ul>Rietvield(Guido van Rossum)<br /><ul><li>based on Subversion
Upcoming SlideShare
Loading in...5
×

Git and Gerrit Code Review - Tech Talk - 2010_09_23

4,787

Published on

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,787
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
135
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "Git and Gerrit Code Review - Tech Talk - 2010_09_23"

  1. 1. Code Review <br />using<br />Gerrit, EGit and Git<br />http://code.google.com/p/gerrit<br />http://eclipse.org/egit<br />+<br />=<br />Matthias Sohn (SAP)<br />matthias.sohn@sap.com<br />Twitter: @masohn<br />
  2. 2. Overview<br />Hudson, Mylynintegration<br />Tools<br />any VCS,change <br />management, audit tools<br />Gerrit<br />EGit, JGit<br />CVS, SVN, bugzilla<br />mailing lists<br /> mailing lists<br />massive peer review<br /> review contributions<br />review critical areas<br />Interaction<br />bazaar<br />cathedral<br />technical quality<br />over all<br />protect IP of member companies<br />classical QA, governance, regulations<br />Motivation<br />Code Review | © 2010 by M. Sohn<br />
  3. 3. Peer Code Review – What is it ?<br />Guido van Rossum [1]<br />When one developer writes code, another developer is asked to review that code<br />A careful line-by-line critique <br />Happens in a non-threatening context <br />Goal is cooperation, not fault-finding <br />Often an integral part of coding process<br />Debugging someone else's broken code<br />– Involuntary code review: Not so good; emotions may flare<br />[1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf<br />Code Review | © 2010 by M. Sohn<br />
  4. 4. Code Review – Benefits<br />Guido van Rossum [1]<br />Four eyes catch more bugs<br /><ul><li>Catch bugs early to save hours of debugging</li></ul>Enforce coding standards<br /><ul><li>Keep overall readability & code quality high</li></ul>Mentoring of new developers <br /><ul><li>Learn from mistakes without breaking stuff</li></ul>Establish trust relationships <br /><ul><li>Prepare for more delegation</li></ul>Good alternative to pair programming<br /><ul><li>asynchronous and across locations</li></ul>[1] http://code.google.com/p/rietveld/downloads/detail?name=Mondrian2006.pdf<br />Code Review | © 2010 by M. Sohn<br />
  5. 5. Review - how does it Linux ?<br />Collected from http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php<br />Code Review | © 2010 by M. Sohn<br />
  6. 6. Roles<br />Contributors<br />Proposechanges<br />Review changes(all changesarereviewed)<br />Test, ...<br />Maintainers<br />Benevolent dictator<br />OneMaintainer per subsystem<br />Lieutenant hierarchy<br />Final decision on inclusionof a change<br />Code Review | © 2010 by M. Sohn<br />
  7. 7. Guiding Principles<br />Technical quality over all<br />Code quality outweighs<br />Company plans<br />User desires<br />Existing practice<br />Developer status<br />Long-term view<br />Kernel developers expect to be maintaining the code 5-10 years<br />Massive peer review<br />No code is perfect<br />it can always be improved<br />heed requests forchanges<br />Code Review | © 2010 by M. Sohn<br />
  8. 8. Guiding Principles<br />No ownership of code<br />Even code you wrote<br />No regressions<br />...even to fix other problems<br />“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<br />No inherent right to inclusion<br />Changes require justification<br />Other solutions may win out<br />Code Review | © 2010 by M. Sohn<br />
  9. 9. Fundamental unit of work is the patch...<br />Identifies your exact set of changes<br />Encapsulates changes to all modified files<br />Resilient across changes to underlying files<br />© SAP 2009 | 9<br />Patches<br />Code Review | © 2010 by M. Sohn<br />
  10. 10. © SAP 2009 | 10<br />Code Review on Mailing List<br />Code Review | © 2010 by M. Sohn<br />
  11. 11. Patch Lifecycle<br />DesignThis is where the real requirements for the patch -- and the way those requirements will be met -- are laid out. <br />Early review Patches are posted to the relevant mailing list, and developers on that list reply with any comments they may have. <br />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.<br />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<br />Stable release The number of users potentially affected by the patch is now large, so, once again, new problems may arise.<br />Long-term maintenance The original developer should continue to take responsibility for the code if it is to remain useful in the longer term.<br />Code Review | © 2010 by M. Sohn<br />
  12. 12. The targetisalwaysthemainlinekernel<br />Maintainer: Linus Torvalds<br />2-3 month release cycle<br />Release cycle<br />© SAP 2009 | 12<br />Trees<br />Code Review | © 2010 by M. Sohn<br />
  13. 13. Trees<br />Patches travel through trees<br />Code Review | © 2010 by M. Sohn<br />
  14. 14. Git<br />… a distributed revision control system built by the Linux project to automate patch workflow<br />Distributed means no central repository<br /><ul><li>No central authority!
  15. 15. Easy offline usage
  16. 16. Easy to fork a project
  17. 17. Protected against manipulation by cryptographic hashes</li></ul>Really good at merging<br /><ul><li>Coordination only needed "after the fact”
  18. 18. Easier to rejoin (or refresh) forked projects</li></ul>Structured around commits (i.e. patches)<br /><ul><li>Integrates with email channel
  19. 19. Tools for identifying problem commits (gitbisect)
  20. 20. Tools for restructuring branches w/ specific commits</li></ul>Code Review | © 2010 by M. Sohn<br />
  21. 21. Review - how does it Eclipse ?<br />Code Review | © 2010 by M. Sohn<br />
  22. 22. The Eclipse Way<br />Copied from Pat Huff (IBM)http://www.eclipsecon.org/2008/sub/attachments/Managing_Eclipse_Adoption_in_the_Enterprise.pdf<br />Code Review | © 2010 by M. Sohn<br />
  23. 23. Eclipse - Roles<br />Committer<br /> Formally elected<br />Can commit own changes without review<br />Contributor<br />Small changes<br /> reviewed by committers<br />Bigger changes<br /> also formal IP review by legal team in separate protected Bugzilla<br />Review Tool<br />patches attached to bug in Bugzilla<br />comments in Bugzilla<br />Code Review | © 2010 by M. Sohn<br />
  24. 24. Code Review in Bugzilla<br />Code Review | © 2010 by M. Sohn<br />
  25. 25. Eclipse – Review Process<br />Contributors<br /><ul><li>create patch using CVS, SVN, Git
  26. 26. attach patch to bug in Bugzilla</li></ul>Committers<br /><ul><li>do code and IP review
  27. 27. comment, vote in Bugzilla
  28. 28. create CQ for changes needing IP review
  29. 29. commit accepted changes</li></ul>IP Team<br /><ul><li>does IP review bigger changes from contributors</li></ul>Code Review | © 2010 by M. Sohn<br />
  30. 30. Eclipse – Review Process<br />Review not done for all changes<br />Review tedious for contributors (and also for committers mentoring contributors)<br />Code Review | © 2010 by M. Sohn<br />
  31. 31. Git at Eclipse (since 2009)<br />Eclipse defined a roadmap to move to Git<br />EGitis an Eclipse Team provider for Git<br /><ul><li>http://www.eclipse.org/egit/</li></ul>JGit is a lightweight Java library implementing Git<br /><ul><li>http://www.eclipse.org/jgit/</li></ul>The goal is to build an Eclipse community around Git.<br />EGit/JGit are still beta and we want to establish a feedback loop to improve the tooling.<br />Code Review | © 2010 by M. Sohn<br />
  32. 32. History JGit/EGit<br />2005    Linus Torvalds starts Git<br />2006    Shawn Pearce starts JGit<br />2009    Eclipse decides for Git Roadmap           JGit/EGit move to eclipse.org           SAP joins<br />3/2010 Released 0.7(first release at Eclipse)<br />            Diff/Merge Algorithms, Automatic IP Logs<br />6/2010 Released 0.8 (Helios)<br />           Usability Improvements, Git Repositories View, Tagging<br />9/2010Released 0.9 (Helios SR1)<br />            Merge, Synchronize View, .gitignore<br />Planned 12/2010 0.10 3/2011 0.11 6/2011 1.0 (Indigo)<br />Git at Eclipse | © 2010 by M. Sohn<br />
  33. 33. Review - How does it look with Gerrit ?<br />Code Review | © 2010 by M. Sohn<br />
  34. 34. Gerrit Code Review<br />Gerritis a Code Review system based on JGit<br /><ul><li>http://code.google.com/p/gerrit/
  35. 35. Also serves as a gitserver
  36. 36. adding access control and workflow
  37. 37. Used by
  38. 38. Androidhttps://review.source.android.com/
  39. 39. JGit, EGithttp://egit.eclipse.org/r/
  40. 40. Google, SAP, …
  41. 41. Eclipse wants to use it …</li></ul>Code Review | © 2010 by M. Sohn<br />
  42. 42. History GerritCode Review<br />Gerrit = 4th Generation code review @ Google<br />Google started code review with a Linux like review process<br /><ul><li>patch based
  43. 43. tooling based on Perforce CLI</li></ul>Code Review | © 2010 by M. Sohn<br />
  44. 44. Google - Web based code review tools<br />Mondrian(Guido van Rossum)<br /><ul><li>based on Perforce, Google infrastructure
  45. 45. Google proprietary</li></ul>Rietvield(Guido van Rossum)<br /><ul><li>based on Subversion
  46. 46. Open Source hosted on GoogleApp Engine</li></ul>Gerrit(Shawn Pearce)<br /><ul><li>started as a fork of Rietvield
  47. 47. based on JGit and GWT
  48. 48. Open Source (Android)
  49. 49. Apache 2 license </li></ul>Code Review | © 2010 by M. Sohn<br />
  50. 50. Gerrit – Extreme Branching<br />Code Review | © 2010 by M. Sohn<br />
  51. 51. One Branch per Feature<br />Master branch contains only reviewed and approved changes<br />master moves from good to better state after each (approved) change<br />Each feature branch is based on the Master branch<br />stable starting point<br />coupling only with approved changes when developing new code<br />A change can really be abandoned because<br />no other change can depend on a not yet approved change<br />gerrit will automatically reject a successor change of an abandoned change<br />Code Review | © 2010 by M. Sohn<br />
  52. 52. Gerrit – Rebase<br />Code Review | © 2010 by M. Sohn<br />
  53. 53. Gerrit – Linear History (optional)<br />Code Review | © 2010 by M. Sohn<br />
  54. 54. Gerrit - Workflow<br />Code Review | © 2010 by M. Sohn<br />
  55. 55. Gerrit<br />http://egit.eclipse.org/r/ - change,825<br />Code Review | © 2010 by M. Sohn<br />
  56. 56. Gerrit- Workflow <br />Every change is reviewed<br />- Authors can invite reviewers<br /> - Complex changes reviewed by many<br />Look at the change<br />- Comment on how to improve it<br />- Discuss in context of the change<br />Download the change<br />- test it<br />- improve it<br />Discussion usually leads to new improved change<br />Code Review | © 2010 by M. Sohn<br />
  57. 57. Gerrit – Lifecycle of a Change<br /><ul><li> create local topic branch
  58. 58. commit change
  59. 59. push it for review
  60. 60. review
  61. 61. automated verification</li></ul>topic<br />master<br />1<br />a<br />Code Review | © 2010 by M. Sohn<br />
  62. 62. Gerrit – Lifecycle of a Change<br /><ul><li> create local topic branch
  63. 63. commit change
  64. 64. push it for review
  65. 65. review
  66. 66. automated verification</li></ul>topic<br />master<br />1<br />a<br />master<br />topic<br /><ul><li> refine based on review
  67. 67. push new patchsets until review votes ok</li></ul>c<br />3<br />b<br />2<br />a<br />1<br />Code Review | © 2010 by M. Sohn<br />
  68. 68. Gerrit – Lifecycle of a Change<br /><ul><li> create local topic branch
  69. 69. commit change
  70. 70. push it for review
  71. 71. review
  72. 72. automated verification</li></ul>master<br />topic<br />master<br />d<br />topic<br />1<br />a<br />c<br />3<br />b<br />2<br />master<br />topic<br /><ul><li> refine based on review
  73. 73. push new patchsets until review votes ok</li></ul>a<br />c<br />1<br />3<br />b<br /><ul><li> Submit may lead to server-side merge
  74. 74. or merge / rebase before push</li></ul>2<br />a<br />1<br />Code Review | © 2010 by M. Sohn<br />
  75. 75. Code Review – Our Experience <br />Review all changes!<br />Review takes time (1 day … weeks) <br />Implies parallel workflow <br />Every team member should do reviews regularly<br />Authors have to wait for the review to happen<br />Git & Gerrit help a lot here<br />Code Review | © 2010 by M. Sohn<br />
  76. 76. Code Review – Tips<br />Small changes are much easier to review<br />A change should logically do one thing (not many)<br />No change shall break build or tests<br />Split big changes into series of digestible changes <br />(patch series)<br />- These changes depend on each other<br />- Last change should switch the new feature on<br />Commit message should explain Why<br />- The What should be obvious from the code change<br />Code Review | © 2010 by M. Sohn<br />
  77. 77. No Free Lunch ? -- DEMO<br />Code Review | © 2010 by M. Sohn<br />
  78. 78. Conclusion<br />Code Review rocks !<br />Gerrit enables a nice code review workflow <br />DVCS like Git are powerful<br />Git supports convenient branching and merging <br />Gitis very fast and scales well<br />Code Review | © 2010 by M. Sohn<br />
  79. 79. Gerrit Code Review<br />Gerrit developed at http://code.google.com/p/gerrit<br />https://review.source.android.com/Gerrit for Android projects (also Gerrit)<br />Code Review | © 2010 by M. Sohn<br />
  80. 80. Git at Eclipse<br />EGit/JGit developed at http://egit.eclipse.org<br />http://git.eclipse.org/hosts live Eclipse Git repos<br />Virgo, Mylyn Review, ScalaModules, SWTBot …<br />http://dev.eclipse.org/git/index.html git mirrors for CVS<br />Read-only copies kept up-to-date<br />Can clone with git:// or http://<br />Code Review | © 2010 by M. Sohn<br />
  81. 81. Git Resources<br />Ask questions on the EGit forum or egit-dev/jgit-dev lists<br />http://git-scm.com/documentation is your friend<br />If you want comedy, watch Linus' talk at Google<br />http://www.youtube.com/watch?v=4XpnKHJAok8<br />Read the Pro Git book - http://progit.org/book/<br />Code Review | © 2010 by M. Sohn<br />
  82. 82. Gerrit Code Review - Outlook<br />Upcoming proposal for MylynGerrit Connector<br />Port from SQL DB to Cassandra<br />Store review comments as git notes for offline review<br />Support for change dependencies across repositories<br />…<br />Code Review | © 2010 by M. Sohn<br />
  83. 83. git-add<br />git-format-patch<br />git-shortlog<br />git-relink<br />git-rev-parse<br />git-am<br />git-gc<br />git-show<br />git-remote<br />git-show-branch<br />git-archive<br />git-grep<br />git-stash<br />git-repack<br />git-verify-tag<br />git-bisect<br />git-init<br />git-status<br />git-replace<br />git-whatchanged<br />git-branch<br />git-log<br />git-submodule<br />git-annotate<br />git-bundle<br />* git-merge<br />* git-tag<br />* git-blame<br />git-checkout<br />git-mv<br />git-config<br />git-cherry<br />.gitignore<br />* git-cherry-pick<br />git-notes<br />git-fast-export<br />git-count-objects<br />git daemon<br />git-clean<br />* git-pull<br />git-fast-import<br />git-difftool<br />* HTTP support<br />git-clone<br />git-push<br />git-filter-branch<br />git-fsck<br />* Mylyn integration<br />git-commit<br />* git-rebase<br />git-mergetool<br />git-get-tar-commit-id<br />* Staging View<br />git-describe<br />git-reset<br />git-pack-refs<br />git-help<br />* Synchronize View<br />git-diff<br />git-revert<br />git-prune<br />git-merge-tree<br />History View<br />git-fetch<br />git-rm<br />git-reflog<br />git-rerere<br />Repositories View<br />Features EGit 0.9<br />* planned for next release, supported, partial, missing, irrelevant for EGit<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×