Name of the blog

Short description of the blog

SDC, Part 8: Code reviews using features

We've seen how developers can work with both tasks (for small work items) and features (for larger work items). This blog will look at how code reviews can be achieved using features.

Why Reviews?

As a developer completes all the tasks required for a feature, without code review, the option to 'Complete' on the feature is used. Submitting the resulting changeset would merge the feature into the parent Version immediately, close the feature, and stop any code changes from being merged into the feature (from the parent Version). This means that the developer's code is added to the main (parent) Version without any kind of formal inspection or review by someone other than the developer.

This is perfectly acceptable and a common way of working, but in many cases it is a requirement for code to be reviewed before being submitted into a main version. By using reviews, a feature can be given to a manager (or group of), to perform a review of the code changes. The result of the review is either to accept the changes, and commit them to the Version, or reject them.

When rejecting a review it is usual for the feature to be handed back to the developer to complete any outstanding requests.

How to enable Reviews

Because of the isolation of a feature it is very simple to use it as a platform to review the code. Reviews 'come for free' simply by assigning the feature to a user or group of users other than the developer.

So for example.. 

A feature is assigned to a 'Lead Developer' (who is responsible for the review) - this makes them the owner of the feature, and the tasks of that feature are assigned to a 'Developer'. The developer completes the tasks as previously described in earlier blogs. As the developer completes the last task of the feature, this feature appears in the Lead Developer's list of 'Pending Features' (under 'My Tasks' and also 'Workspaces' tabs)..

Here the Lead Developer clicks on the 'Complete' button and is presented with the changeset dialog showing the files to be reviewed. Each file can be viewed and changes scrutinised. The 'Submit' button is used if the changeset is acceptable. This results in the changeset being merged into the parent Version. 

If it is decided that the changeset should not be submitted (ie. rejected) then the dialog can be closed and the Lead Developer can create new tasks for the feature and assign them to the developer.

These tasks would then appear under the Developer's 'My Tasks' list as before, and the feature would no longer appear in the Lead Developer's task list, until the new tasks are completed.

In Summary


  • The isolation of a feature allows for an easy way to perform code reviews.
  • By assigning the Feature to the manager and the tasks to the developer, the review process is automated.
  • The reviewer can accept a feature by submitting the changeset, or introduce new tasks to the feature for the developer to perform.

In the next blog we will focus on the project manager again and look at project reporting.