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.

 

 

Policies in Azure Resource Manager for better conventions management

Conventions are a really good idea in general - they prevent you from handling the whole mess which appears sooner or later. While it's pretty obvious when working with your codebase(we have plenty of different tools), it's still not so popular when you're managing your resources in the cloud. This post is going to encourage you to use them and present possible use cases.

Why not roles?

In Azure you can also find a term RBAC, which stands for role-bases access control. While you can find it useful to assign e.g. admin role only for those few people "who know, what they're doing", it's still more user-centric. You can imagine a situation, when you have different teams working on different projects. Different people have different opinions and experience and their choices are dictated by their current point of view. 

Now imagine giving them access to the production environment(I'm aware of the fact that normally access restricted - let's pretend we forgot about this rule). You can select who can do anything on production. What you cannot do is to restrain him or her from provisioning a G5 VM for 5k Euros per month. This is where policies come to play.

Creating and assigning a policy

You have multiple options when it comes to selecting a tool to manage your policies. In fact, you can choose either a REST API, Powershell or Azure CLI. For me the easiest way to work with policies was to use Powershell cmdlets, I strongly encourage you to select tool which suits you the most. 

To make a policy effective you have to perform 2 steps - create it and assign it to the resource group. This is another great feature - you can have your policies predefined and attach them to different resource groups as you wish. It's super easy to automate also if you wish.

To create aand assign policy you can use following command:

/
$policy = New-AzureRmPolicyDefinition -Name regionPolicyDefinition -Description "Allow only one region" -Policy '{    
  "if" : {
    "not" : {
      "field" : "location",
      "in" : ["northeurope"]
    }
  },
  "then" : {
    "effect" : "deny"
  }
}'

New-AzureRmPolicyAssignment -Name regionPolicyAssignment -PolicyDefinition $policy -Scope /subscriptions/{SubscriptionId}/resourceGroups/{ResourceGroup}

I used examples from this page and modified them slightly. What this code does can be shortened to "create a policy in subscription & assign it to the resource group". Now let's try to create any kind of resource in this resource group, which is not in the North Europe region. It seems it's not so easy now:

When you go to the details of this error, you'll see something similar to following:

/
{
  "error": {
    "code": "RequestDisallowedByPolicy",
    "message": "The resource action 'Microsoft.Network/virtualNetworks/write' is disallowed by one or more policies. Policy identifier(s): '[{\"policyDefintionId\":\"/subscriptions/{SubscriptionId}/providers/Microsoft.Authorization/policyDefinitions/regionPolicyDefinition/\",\"policyAssignmentId\":\"/subscriptions/{SubscriptionId}/resourceGroups/FunctionApp//providers/Microsoft.Authorization/policyAssignments/regionPolicyAssignment/\"}]'."
  }
}

Managing policies

When you take a look at the documentation of policies, you'll see other options available for policies like viewing already created ones or removing them. I strongly encourage you to read them - there're many different properties, which can be set like the size of VM, storage SKU or even ensuring that storage blob is encrypted. It's a really powerful tool and using it wisely can really ease operations and management.