How can we improve Azure DevOps?

Code Review after tasks in TFS completed

This suggestion is migrated to Developer Community. Please use below link to view the current status.
Now we can perform a code review on checked in code. But my group does incremental check ins and doesn't want a code review after checking in 4 lines of code. We would like to see code reviews after say, the developer has completed a User Story task or a user story. preferrably a task.

77 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

Chuck shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Mike commented  ·   ·  Flag as inappropriate

    +1 to this suggestion.

    It is not about how programmers should commit their changes in a single commit or not in your company so other companies must do the same. The fact is, requirement changes can happen; programmers might switch tasks; people are too busy so work items must be spread out; same feature might be changing programmers; a feature sometimes can be so bigger than 1 or 2 days; debugging, refactoring, etc.

    Not only code reviews, but I think we need a tool to see all file differences of multiple changesets, therefore code reviews, or what files are modified under features or user stories, would be extremely helpful.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I think this feature is super important for code review. I mean how do you expect anyone to review changes from more than one change set otherwise? It'd be ****! And this is exactly what I'm going through currently. My developers are committing their changes at will. Once the task is complete, I need to review their changes. There should be some way for me to see a unified diff from all the relevant change sets. Until this is in place, the code review flow is useless. I mean who completes their task in one commit?

  • Erik commented  ·   ·  Flag as inappropriate

    You shouldn't check in unless you are done with the task, instead use Shelvesets for intermediate checkins. Shelvesets were not that useful in older versions, but as of TFS2012 they now merge when you unshelve rather than just copying over the files, so they work more like a get latest.

  • Rekha Hariram commented  ·   ·  Flag as inappropriate

    I just wanted to add more information to this suggestion. We follow agile and we check in frequently. We create tasks that spans from a day to 3 days. Once the task is completed by the developer it is sent for review. So we have multiple changesets to review. It is very hard to have a good picture of the changes to the same file are across multiple changesets. As of now, we are finding all the files that are affected by that task and go to "view history" of the file and pick a the most recent and the changeset before the task started to get a consolidated view of changes. This suggestion will make this process more easier. I can summarize the suggestion as :

    Show changes from all changesets for a task similar to showing all changes in a changeset.
    This will use a combination of existing features
    1. Change history for a file – compare first and the last changeset number in a task for a file.
    2. Display all affected files like for a changeset.
    3. Could grey out changes from other tasks, or color code differently.
    This will make reviewing a task easy instead of having to look at different changesets.

  • Paul Coste commented  ·   ·  Flag as inappropriate

    Why not just use feature branching, allow them to check in at will, and then do a review upon integrating/merging the code. For example, they can merge down into the branch to resolve any conflicts first, commit those changes, then merge up into the parent branch and request a review on the pending changes.

Feedback and Knowledge Base