Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Code Reviews

DZone's Guide to

Code Reviews

See how Visual Studio Team Services makes code reviews easier with options for pull requests and branch policies.

· DevOps Zone ·
Free Resource

Read why times series is the fastest growing database category.

Reviewing code is a great habit to get into. Code reviews help share knowledge among your team members and help catch bugs before they get into production. But how do you get into the habit of reviewing and avoid the "we don't have time to do this" mentality?

Visual Studio Team Services (VSTS) has some great options that can help make code reviews second nature.

Pull Requests

A lot of source control systems have the concept of pull requests. This is where you request others to review your code usually in a branch and if they approve it, merge it into a main branch.

To create a pull request in VSTS go to the Code section and select Pull Requests. Often VSTS will make a suggestion of what branch to make a pull request for if you don't see this just click the New Pull request button.

Select a branch you want to merge from and a branch that should be merged into (usually you merge into master from a feature branch). Give your pull request a title and description and select who should review your code, this can either be an individual or a group of people. You can also review all the changes that will be reviewed so you can make any last minute changes before it is reviewed.

Now if you are anything like me you want your code merged in as soon as you have created your pull request and there is nothing stopping you reviewing your own code and clicking approve and merge on your own pull request. However, branch policies are a way around this problem.

Branch Policies

Branch policies allow you to specify how your code gets merged in.

Go to the list of branches in VSTS and select branch policy and you will see a whole host of options to customize the merge process. If you do this on the master branch you will not be able to commit any changes to master without it going through a pull request.

The first option enables you to select how many reviewers are needed on your code. If no one else works on your project best not setting this, but for everyone else setting at least one person to review your code is a great practice.

Next, you can ensure that your pull request is linked to a work item, this helps keep ensure you are actually fixing issues and not just making change for the sake of it.

Check for comment resolution is a good setting to enable. This ensures that if your reviewer has commented about you needing to change this line here, it ensures that you do.

Enforce merge strategy allows you to choose between fast-forward merge or squash merge.

Build validation enables the code to be built using a build definition you have configured. This is a great way to check code builds or tests pass before it gets merged in.

The last two options allow you to specify code reviewers and third-party external services.

Learn how to get 20x more performance than Elastic by moving to a Time Series database.

Topics:
devops ,code review ,vsts ,software development ,agile ,debugging

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}