Setting up Tool driven Code Review process Part-2
Going forward in order to overcome the shortcomings described in part one of the blog post it was decided to implement a tool based review process which supported both pre & post review . Some of the pre-requisites for this process could be that it should be simple to use ,informative, scalable & support our existing tech stack. A number of review tools were identified for this process but two of then were short listed for next level
a) Review Board - The tool was selected after evaluating various open source tools like code stricker, rietveld, code collaborator, mondarin etc.
b) Crucible: A very famous paid tool
After DAR(Decision and analysis report) report Review board came out as winner with 2.772 * points and Crucible with 2.847 * points. These two tools were evaluated on 80 criteria. The item with minimum points won. The DAR report has been published below:
Old Process
1)The review typically start at the end of development cycle and is usually performed in one go.
2)The review is always Post commit.
3) The Team lead sends mail to the whole team informing them about the start of Review cycle. Does a bit of administrative work like creating the review document in VSS for that release. (Lot of discussions are held on mails & verbally on issues related to if modules are indeed ready for review)
4) The developers in turn manually create scopes of the code they want to get reviewed and mail them to : 1) Allocated Peers (In case of Peer review ) 2) Technical Consultant (In case of 2nd level review)
5) The developers then wait for their review comments.
6) The reviewers then manually specify the start of review via email.
7) The reviewers go through the code & fill in the review sheet with their comments .Any doubts & discussions are handled verbally or via email.
8) The reviewers send mail to the developers once the code review is complete.
9)The developers then manually go through the comments (Description , severity , Line no ) & start fixing those comments.
10)The Review sheet is further updated with the developers comments (whether the comment is incorporated or not accepted).
11)A mail is send by the team lead to the respective reviewers when their comments are incorporated.
12)The reviewers then go through the sheet & manually check the code to see if their comments are indeed implemented.
13) The review end with the reviewers marking the comments as fixed with a entry in comments column.
New Process ( after introduction of Review board)
Pre Commit Process 1) The review workflow has two roles: Author and Reviewer of the code. 2) The author creates some changes in his local checkout, computes a diff using svn diff > patch.diff, and creates a new review request. 3) The reviewer opens the review request, examines the changes, adds comments, and optionally marks it as good enough to commit "Ship it!". 4) If the code was marked as "Ship it!", the author can now commit his changes. 5) If the code needs some more changes, the author updates the code, creates a new patch with svn diff > patch.diff, and updates the review request with his patch. 6) The reviewer then starts at point 2 again.
Note: Post-commit reviews are reviews made up of changes which have already been committed to source control manager. Pre-commit reviews are reviews made up of changes which are present in author’s workspace and are not yet committed to source control manager.
Post Commit Process : Real world implementation in production involving Quality center has been described below:
Workflow enforcement
In case of pre commit review the developer is also forced to mention the review id while fixing USD & QC defects thereby solving our workflow enforcement issue.













