We recently had the chance to help a major company in Omaha convert from a self-hosted Team Foundation environment to Visual Studio Team Services. This was a big project, since we wanted to include all work items (stories, features, bugs, tasks, etc), shared queries and source code history; as well as a switch from Team Foundation Version Control to the Git protocol.
The conversion itself went off without a hitch. Using git was an entirely new approach for seasoned TFS professionals, but they quickly jumped on board when we showed off Pull Requests.
Pull Requests are a way to put your own code up for a review. This is done via a merge from one branch to another. I like to think of it as, “I request that the main branch pull in my changes.” The team can then look at all of my code changes, and if the pull request is approved, the merge is allowed. Along the way, comments and discussion can be added to any line of code that was changed.
We have found many benefits to using pull requests, including the comments and discussion features:
- Transparency. VSTS actually lets us set a policy that protects the “master” branch from any code that doesn’t come from a pull request. This means that everything is reviewed. The whole team gets an email every time a pull request is created, so we all have the chance to comment and “approve” or “reject” it. Teams can have any strategy they want—we find it useful to let everyone be an “optional” reviewer, but other teams might want to designate a leader, for example, as a “required” reviewer. Regardless, everyone should know about the changes before they happen and be allowed the chance to provide commentary.
- Reliability. We like to make sure the project builds and unit tests pass before a pull request can be approved. This policy can be easily enforced via the VSTS interface. If code has been approved, it can be automatically merged as soon as the build (and tests) are passing. Thus, our “master” branch is always stable and ready to deploy.
- Accountability. When writing code, we always keep in mind that everything we change will show up in the pull request. This means that my scope should be narrow and that everyone can understand the changes. This makes for better code, since we realize that it will definitely be seen.
- Speed. Pull requests can be done asynchronously, since they require branching. So, I can put my code up for review, and work on something else while I’m waiting for someone to take a look. Requesting a review doesn’t slow us down at all, so it’s a required part of our workflow. If changes are required, switching branches and pushing changes is fast and easy, and automatically update the pull request as they happen.
The interface for reviewing pull requests is very nice as well. The page shows updates as-they-happen, so you don’t need to hit “refresh” to watch comments roll in. There are more advanced options, too, for assigning reviewers— for example, we can designate one person the “SQL reviewer”, and any pull request that changes a “*.sql” file must be explicitly approved by this person in order to be merged.
All in all, pull requests are a fantastic feature that has let us evolve our daily workflow and produce great code together.