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

The need for DevOps innovation has never been greater. Get the results from over 100 business value assessments in this whitepaper, Digital Darwinism: Driving Digital Transformation, to see the positive impact of DevOps first hand.

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.

Interested in Kubernetes but unsure where to start? Check out this whitepaper, A Roundup of Managed Kubernetes Platforms from Codeship by Cloudbees, for an overview and comparison of Kubernetes platforms. 

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 }}