Branch policies are a great way to keep your code quality high, but strict build gates can sometimes introduce too much friction into the developer inner-loop.  To developers working with pull request build policies, this will sound familiar:  You have a PR that’s been approved and is ready to merge – but right before you’re ready to click Complete Merge, another developer’s changes are merged in, putting your PR out of policy (and requiring another build).  Definitely a source of frustration.

To help streamline the pull request workflow, yet still offer protection on your branches, we added some new options to the Team System build policies.

“Buddy Build” Policy

The first of the new build policy options is what we sometimes call a “buddy build” policy – that idea being that you’re having someone else build your changes to avoid the “it worked on my box” problem.  In this case, the “buddy” is the build machine, and like the existing build policy, each time new change are added to the source branch of the PR, those changes are automatically detected and built.

The big difference with this policy option is that when the target branch is updated, a new build is not required.  In the policy config UI, we expose this setting under the options for what to do when the target branch is updated as Don’t require a new build.

So, in the case above where you’re about to merge your PR, and someone else merges their changes, you won’t be forced to rebuild.  Instead, you’ll see an option to re-evaluate the merge:

Re-evaluating the merge will create a new merge commit and check for conflicts.  Assuming there are no conflicts, you’ll see a message about the target branch being updated with an option to rebuild.  With the buddy build policy, all you need is one good build to get approval, so the rebuild would be optional in this case.

Build Expiration

The second new option for handling builds when there are changes to the target branch enables teams to strike a balance between strict builds and the more relaxed buddy build.  The option to Require a new build if older than n hours works pretty much how it sounds.  Like the buddy build policy, a change to the target branch doesn’t immediately invalidate the current build.  Instead, it sets an expiration time for the build based on the configuration – if the option is configured for one hour, a change to the target branch will cause any PR build to expire one hour from the time it originally completed (not one hour from the time the branch was updated).

In the case where a build is successful and the target hasn’t changed, the build will be good indefinitely.  If the build is older than the expiration window and then the target is updated, the build will immediately be invalid and a rebuild will be required.

How should I choose between the build policy options?

Choosing an option for your build policy comes down to choosing between the risk of introducing a build break and developer friction.  On the extremes, no build policy has the least friction and biggest risk of build break and the option to Always requires a new build prevents build breaks but can cause friction as the activity in the repo increases.

If your risk tolerance for a build break is high, the buddy build might be a good option.  If you have a long build time, this might also be a good option (though investing to speed up your build would be a good idea, too).

The build expiration feature is a good middle ground that allows teams to tweak the longevity of PR builds.  You can simultaneously keep out those stale PRs that had a successful build last week and not require a rebuild when an unrelated change is merged right before you complete your PR.

For more details on how to configure build policies for your pull requests, checkout our documentation on MSDN.