There are many new features that Microsoft intends to introduce in VS11 / TFS 11. In this article I am going to take an overview of the code review feature which is one of the new standard features. Till TFS 2010, we used to implement code review workflow with the custom work item, custom check-in policy and a server side event handler. With TFS 11, we will not need to do some parts of this customization since Microsoft has also provided these parts built-in.  

One major change in approach that Microsoft provides in VS 11 /TFS 11 is the default tools built-in along with work items. There are a some new work items types that can be accessed using those tools only and not directly in their form in Visual Studio. Code Review Request and Code Review  

Response is a pair of work items like those. They have built in tools that integrate in Team Explorer and provide a special UI to manipulate data and state of those work items.  

Note: VS 11 / TFS 11 are only code names of the Visual Studio / Team Foundation Server planned to be released in near future and not the final brand names/  

Let us take a case a where a developer named Arun has modified a line of code and now seeks to check-in the code. 

 Before he does the check-in, it is desirable that he gets the code reviewed by a peer or a senior developer in the team. In Team Explorer under Pending Changes, he finds an option to Request Review.  

 Arun selects that option (Request Review) that opens the form to create a new Code Review Request work item. He assigns that work item to another developer named Subodh from the same team. 

He also provides a title of the work item and Submits the Code Review. While saving the work item, the code that was changed (Form1.cs) is shelved and a reference to that is added to the work item.  

Arun can view that submitted code review request under My Work page in the Team Explorer on his computer.  

 When developer Subodh opens My Work page in team explorer on his computer, he can see that submitted work item (Code Review Request) appearing under the Code Reviews and Requests node.  

 He clicks on that node to expand and views details of that code review request.  

 Subodh can also view the shelveset that contains the Form1.cs file. When he selects the file from that shelveset, he can see two lines for the changed line of code. The previous state of the same line appears with pink background and the state as changed by Arun appears with yellow background.  

Subodh decides to accept the change but also decides to provide some review comments. He adds the comments on the Code Review tool that is showing the details of Code Review Request work item.

 He provides the comments for the Form1.cs as well as at overall Review level.  

 Now Subodh clicks on the Accept button where he chooses to accept the code changes with comments. At this time, TFS creates a new work item of the type Work Item Response and links that to the original work item of the type Code Review Request with Parent (Request) – Child (Response) relationship.  

 Now Arun can view the changed state of Code Review that he had requested.  

 He associates this work item with the check-in that he is doing and completes the check-in operation.

 He can view the associated work item by going to the Changeset details.  

 Code Review Request work items appears as Closed.  

 If a query to view hierarchy of work items is created, it shows the Code Review Requests and Code Review Responses with Parent – Child relationship between them.  

 In this workflow, there still is no compulsion made on Arun to get the code review done. It is desirable to have such a compulsion. That may be implemented by implementing a custom check-in policy. It is also desirable to have a custom group of developers who are designated as code reviewers and Code Review Request work item can be assigned only to them. In the next article, I will try to provide a solution for these desires that I have mentioned. Stay tuned!