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

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

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

15. Easy offline usage

16. Easy to fork a project

19. Tools for identifying problem commits (gitbisect)

20. Tools for restructuring branches w/ specific commitsCode 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

27. comment, vote in Bugzilla

28. create CQ for changes needing IP review

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

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

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

43. tooling based on Perforce CLICode Review | © 2010 by M. Sohn

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

58. commit change

59. push it for review

60. review

61. automated verificationtopic master 1 a Code Review | © 2010 by M. Sohn

63. commit change

64. push it for review

65. review

67. push new patchsets until review votes okc 3 b 2 a 1 Code Review | © 2010 by M. Sohn

69. commit change

70. push it for review

71. review

74. or merge / rebase before push2 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