Edit: VSTS is now called Azure DevOps but it’s essentially the same thing with a different UI. I have written an Azure DevOps guide series here.

Previously, I covered how to build and release all git branches in TFS 2018 and VSTS. This time, I’ll improve on that and show how to build the merge results of pull requests. Using this method gives you greater safety and more confidence that your code is correct.

Pull Requests

If you’re following a sane agile workflow using git, then chances are that you never commit directly to your master branch and always merge in code via pull requests (PRs). This allows you to review and test the proposed change to master before going ahead with it. While building branches as you go along is good for catching errors early in development, when it’s time to open a pull request then you want higher assurances of quality.

The way to do this in Team Foundation Server 2018 and Visual Studio Team Services is to use branch protection. Follow these steps.

Protect The Branch

The first step is to locate your branch (e.g. master) and select “Branch policies” from the ellipses (...) menu.

You then get a rather comprehensive screen of options.

Scared Of The Policies

Don’t be scared, there are a lot of options but you don’t need them all.

Requiring reviewers allows you to enforce code review by other members of the team. Being TFS, this is excessively configurable. However, simply setting a single minimum reviewer is usually enough.

Linked work items is very useful but the most important section is build validation. If you add your continuous integration (CI) build to this list then your PR will be automatically built and can’t be merged until the build has compiled with all unit tests passed.

As the build is run on the result of the PR (e.g. merging your feature branch into master) then as soon as you merge one PR all the others will require rebuilding. To reduce the overhead of this, you can set a grace period for green builds to expire. If you don’t have a huge amount of PRs in progress at once then it is safest to expire builds immediately.

You can always manually re-run a build from the PR review page, and if there are merge conflicts then you will need to fix them and re-build anyway. Usually this will involve merging in the opposite direction, e.g. merging the latest master into your feature branch and re-pushing.

The Results

If you look in the logs of your build you can see that the compiled code is the result of a merge and not just the source of the feature branch.

When the build completes you will see the result on the pull request review page, along with any other branch protection policies.

When all of the required policies are ticked off then you can approve and complete (merge) the pull request. These are discrete steps for some reason but you can set auto-complete (if, for example, you are waiting for a build to run).

Disadvantages

Aside from the poor discoverability and overly-complex configuration, the system works quite well, and is more capable than previous workflows that I’ve used with GitHub. The main downside is that only the PR number is shown in the list of builds, not the name. It would be better if the pull request name was shown, as the branch name is when building all branches.

If you’ve read this far and are into agile and continuous integration/deployment/delivery then you’ll probably like my new book.