CollabNet TeamForge 6.2 onward integrates Git using Gerrit – an open source code review system designed around Git workflows. Gerrit has been in use at numerous open source projects like Android, Eclipse, OpenStack etc. and also catching up well at enterprises.
Peer code review has many advantages, reducing if not completely eliminating possibilities of shipping ‘bad code’ by having more eyeballs looking at code changes. A peer code review process starts as soon as a developer is done with his/her change in code base and pushes it into a review system. Code review requires human effort and thus is more expensive. Hence, it is worth verifying whether changes compile, build and even further pass basic quality gates (static code analysis, unit test, etc.) before the code gets reviewed by a human. It would be practical if code to be reviewed first gets verified by some automated system before some human effort gets spent on it
Jenkins is a popular Continuous Integration tool to get early feedback. If it is set up along with SCM and build & test tool chain, it posts results of verification soon after code gets committed to ’blessed repository’ (central repository). With Gerrit code review and Jenkins Gerrit Trigger Plug-in, it is now possible to verify code before it gets merged to blessed repositories but right after developers are done with their changes and ready for review feedback: First, developers push their code changes for peer review into special Gerrit review branches rather than pushing them directly to the anticipated target branches in blessed repository. Jenkins can then grab those changes almost immediately, compile, run verification checks and provide earliest feedback possible to developers as well as to peers who are invited for code review. Workflow can be illustrated by the picture below:
Once checks pass /fail, Jenkins automatically updates the corresponding review request in Gerrit with its build results. In case check fails, it’s a signal to rework the change for the developer who posted the review request. Otherwise, it’s an assurance of basic quality compliance (depending on quality checks set up on Jenkins) of the change posted for review. It’s also a hint to a human reviewer whether to go ahead with code review or not. After code review, the reviewer can decide to submit this change to blessed repository from Gerrit WebUI or reject it if needed. If submitted, Gerrit will automatically merge the change to the target branch.
The following screen-cast (It can be seen here and downloaded from here) shows how one can set up such workflow using our TeamForge Git/Gerrit Integration and Jenkins. Pre-requisite would be TeamForge v 6.2 with Git Integration and Jenkins continuous integration server in place (Visit our Build & Test page for more info). On developer side, only basic knowledge of Git and Gerrit is required.
In the workflow depicted in the screencast, Jenkins is configured to act as a ‘verification tool ‘. Every single code review request posted to Gerrit by a developer gets a vote (in form of Jenkins build results). Without Jenkins vote, changes cannot be submitted to blessed repositories. This way one can ensure minimal quality in code before it gets reviewed and earliest feedback. It is also possible to configure Gerrit Trigger plug-in that Jenkins’ opinion is not binding. If a build fails, the human reviewer can still decide to go ahead. In this case, Jenkins opinion is to be configured as ‘code review’ vote, which can be overridden by another review. This can be typically done/advisable when team’s CI tool chain is not set up properly or is less trustworthy, which shouldn’t block code review
Setting up Gerrit code review workflows from scratch is quite complicated and cumbersome. CollabNet TeamForge enables enterprises to make use of preconfigured Git/Gerrit workflows out of the box. It also manages RBAC (Role Based Access Control) and hosting Gerrit/Git repository instances for you. Learn more