You shall not push - branch policies in VSTS

When working on a codebase with a team, you always want to make sure, that everything is kept clean and works smoothly. You have git-flow, you have code reviews - they ensure, that everyone can work without impacting others and the main branch is secured. There's one issue however - by default you cannot force team members to go through the whole process - creating a feature branch, pull request, code review. Fortunately VSTS allows you to set a branch policy, which will ensure, that no one breaks the rules.

Setting a branch policy

TO set-up a branch policy just go to Code->Branches page. Choose whichever branch you want and select Branch policies item.

You'll see a page, where you can choose to protect this particular branch. When you select the checkbox, you'll see different options to make sure it is secured. We'll go through each one to get a basic understanding what it gives us.

Minimum number of reviewers

It allows us to define what is the minimum number of reviewers to actually complete a pull request. What is important here is Allow users to approve their own changes checkbox - if you want to force, that someone has reviewed a PR, make sure it is not checked!

Check for linked items

Useful when working with VSTS issue tracker. Allows you to block a PR if a work item hasn't been linked to it.

Check for comment resolution

My favorite. Forces an author of a PR to make sure, that each comment has been reviewed and accepted. 

Build validation

Allows you to link a build definition to queue a build for a PR to make sure, that feature branch passes through the whole pipeline. No more broken builds!

Results

When a branch policy is set, let's try to do following thing - push a commit directly to a develop branch(or any other branch which is protected) and complete a pull request.

Pushing a commit directly to the protected branch will result in an error

In this case both build and approvals weren't finished

Summary

As you can see in VSTS you can easily set a branch policies, which will help you secure your main branch from broken features. What is more, they will ensure you, that each team member follows the same process and no change can affect other team members.

 

 

Running additional VSTS agents in Azure

When working in a smaller team or on a small project, you usually aim to reduce costs of your development pipeline. This is also true for huge projects, but there we're talking about bigger budget and money. When working with a free VSTS subscription, you're limited to only 1 hosted pipeline(and 4 hours / month) to run your builds and release. To be honest - it's nothing when you have real CI/CD set up and working. However, if you consider a fact, that you also have 1 private pipeline, it's possible to mitigate this problem.

Hosting your own agent

VSTS allows you to host and connect your own agents running on your machines. It's a great way to take advantage of a private pipeline when hitting a limit of 4 hours and allows you to have a backup when you need more builds and releases in a short period. To use an agent you need two things:

  • a machine which will host it
  • an installer

A good idea to get a machine is to use your existing Azure subscription(especially when you have MSDN/BizSpark) and create a VM, which can be started and stopped easily. Another thing are capabilities of your machine, which have to match requirements for your build(e.g. MSBuild, Grunt, gulp and so on). 

Get agent screen will help to both determine what is needed to install it and how to do it

Because of capabilities, using different(you can choose from Windows/OSX/Linux) agents can be easier or more difficult. In the future I will show you how to set up e.g. Linux agent, for now we'll focus on the Windows one.

The easiest way is to create a Visual Studio VM from the marketplace in Azure Portal. That way you will have most components needed for a build already installed and configured. 

Usinga Visual Studio virtual machine will ease whole process a lot

To get an installer you have to go to Agent queues screen in VSTS and click the Download button. As present in a one from the screens above, information needed to install and configure it are already there so I won't reinvent a wheel and just ask you to go through it by yourself.

Configuration

Configuration of your agent is pretty straightforward. When you enter following command:

/
C:\your_agent_directory> .\config.cmd

You'll be asked a couple of questions regarding your VSTS account, a name for an agent, agent pool and a method of authentication. The easiest way to authenticate is to use PAT(Personal Access Token) which can be generated here: https://{your_account}.visualstudio.com/_details/security/tokens.

Once you've configured your agent, you can run it with a .\run.cmd command. If everything's all rights, when you go once more to the Agent queues screen, you'll see your build agent available in the selected agent pool:

Building and releasing on your agent

So far so good - we have additional build agent, which can be used in our private pipeline. But what we have to do to schedule a build and a release? 

Builds

Go to the Builds screen. When you click on the Queue new build... button, you will be asked to select a couple options related to a build. The one we're interested in is Queue. Just selected the one which have your build agent configured and click Ok. Your build should start though you've used all available minutes from the hosted pipeline.

Selecting a different queue will allow you to use a different pipeline

Releases

Releases are a bit tricky. When triggering a release you have no option to specify a queue. To do so you have to go to a specific release definition and find Run on agent link above release steps. When you click on it, it will show you another screen, when you can find Deployment queue list, from which your private pipeline can be selected.

Somehow hidden Run on agent screen allow you to run your releases on your own agent

Summary

In above solution you have to consider costs generated by using a VM to perform builds and releases. Currently you can buy another hosted pipeline for 40$ so it's two times less than a minimum VM needed for a Visual Studio. On the other hand, you can automate it so it works only in your work hours = saving some money. If you have an available subscription like BizSpark, you can save even more money. Both solutions are viable but as you can see, starting another build agent is a very easy task, and can help you when you either want to control usage of your pipelines or to build something, what couldn't be built by a hosted agent.