I'm trying to implement a process so that the manager can Review the code of all developers before the developers can check in to TFS 2013.
Is there any process to require a review of the code by a human being before it is added to a real project?
I'm using TFS 2013 with Visual Studio 2013.
This can be done in three different ways: creating a review from work item query result window. creating a review from work item editor. creating a review from changesets.
Code reviews should happen after automated checks (tests, style, other CI) have completed successfully, but before the code merges to the repository's mainline branch. We generally don't perform formal code review of aggregate changes since the last release.
TFS 2013 supports this out of the box, and is very straight forward to use.
Developer needs to file a request for review in the team explorer:
The target user (in your case, the manager) will get notified (if you've configured the Email settings on the TFS), and can also see the review requests in Team Explorer > My Work.
Reviewer can see all the changes made by the developer, comment on them, and send the comments to the developer. The whole thing happens inside Visual Studio, and all the comments are kept on TFS and can be reported later.
Also, upon completion of review, the reviewer can specify his/her opinion of the changes as "Looks Good", "With Comments" or "Needs Work".
Make sure you read this page on MSDN regarding this: http://msdn.microsoft.com/en-us/library/hh474795.aspx
You can also check out this video on Channel 9: http://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview/Visual-Studio-Ultimate-2012-Using-Code-Review-to-Improve-Quality
EDIT
To prevent check-in without a review, you can use a check-in policy. Here's a custom check-in policy that requires code review before check-in:
https://visualstudiogallery.msdn.microsoft.com/c476b708-77a8-4065-b9d0-919ab688f078
But I should point out that check-in policies are not security mechanisms, think of them as a reminder for the developer to send the code for check-in. Developers can easily override them.
If you really need to prevent any check-ins, you should deny commit permission for developers, and have them send their changes to the manager using a code-review (or shelve set). The manager can then unshelve the changes and commit after reviewing.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With