At our company we are working mainly with TFS and VSTS using GIT repositories. We also set up our project teams with a Lead-Developer. A Lead-Dev has multiple responsibilities. One is to keep the technical overview of all of a projects source-code. We also are heavily committed on Code-Reviews. To do so we use TFS/VSTS pull-requests.
Each feature or bugfix is developed in its own GIT feature branch. A developer can commit to his/her feature branch as often as he/she likes. When the feature is done the Developer places a Pull-Request using the TFS/VSTS web-UI. Here is a good article on how one can place and handle pull-requests with TFS (but the current versions UI is much improved compared to the version showed in the article). This article is about the “Auto-Complete” feature of TFS/VSTS that I – as a Lead-Dev – really like and are getting used to it.
When I get a pull-request from a Developer it shows me several tabs with all kind of information. On the first tab there is a general comment area – a kind of threaded chat. It also shows the summary of the comments left to the source-code files and updates to the pull-request. Think of it as activity-log of the PR – like Facebook for the PR.
One can also leave comments with the “Files” tab directly within source-code. Each comment has a status.
They are tight to a workflow: a reviewer can leave comments and a developer can look through them and mark their status accordingly. Note: once a pull-request is created, it can be updated by simply do a GIT PUSH to it. Using this technique the code get cleaned and comments can get addressed (or further discussed). If everything is fine a reviewer (or Lead-Dev) can “Approve” the code. If CI-Builds are fine too and the PR is linked to workitems (see TFS “branch policies”) the PR then can be “Completed”. The TFS-/VSTS-Server then will do a GIT MERGE (and optionally “squash” and delete the feature-branch).
As a Lead-Dev of multiple projects and libraries I spent some time in reviewing Pull-Requests. Most of them are of good quality but I have suggestions for improvments. I then can leave my comments as described above and instead of “Approve” the PR I can set it to “Waiting for author”. This means I wait on the fixes or answers from the Developer before accepting the pull-request. If there are no major complains I can set the PR to “Auto Complete”.
This means that if all lights are green (Comments are addressed, build succeed, work-items are linked. no merge-conflicts happen) the pull-request will be completed automatically asap.
This is a nice time-saver for me as a reviewer / Lead-Dev as I don’t have to re-visit and manually “Complete” this pull-request. The status is also visible to the Developers so they knows if they addresses the issues the PR will get integrated immediately. It also shortens the turnaround time so the PR is completed/integrated faster because they don’t have to get the Lead-Dev / Reviewer to review everything again. The is handy for the whole team as the team has the new code faster and less chance for merge-conflicts exists.