Contenu connexe
Similaire à Git and Gerrit Code Review - Tech Talk - 2010_09_23 (20)
Git and Gerrit Code Review - Tech Talk - 2010_09_23
- 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
- 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
- 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
- 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
- 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
- 67. push new patchsets until review votes okc 3 b 2 a 1 Code Review | © 2010 by M. Sohn
- 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
- 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