Code Review before checking in to TFS 2013

Amaan Khan picture Amaan Khan · Oct 28, 2014 · Viewed 32.4k times · Source

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.

Answer

Iravanchi picture Iravanchi · Oct 28, 2014

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:

  • Go to Team Explorer
  • Open pending changes
  • Under "Actions" menu, choose Request Review
  • Specify the reviewer, and send.

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.