VSTS v.Next Build Definitions Multiple Branches - azure-devops

Question

I've recently transitioned from XAML builds to v.Next builds. I've always kept one build definition per branch but I see the new system has the ability for a single build definition to trigger on multiple branches and pull requests.
Is this a good idea? What are things to watch out for and the best ways to set this up?
The first couple concerns that come to mind are:
1) Version numbers. How would I handle scenarios such as an old maintenance branch versioning as 1.0., master versioning as 2.0. and a dev build as say 0.2.* so I don't confuse build artifacts? Is there a better way?
2) What if the repos tree has changed? What if master expects to build a .sln in one folder but a dev branch has since moved it to another folder?
Any other concerns and resolutions?

Answer 1

Single build definition to trigger multiple branches and pull request can make VSTS build more flexible. You can choose the way as you need:
If you want to build a certain branch for a build definition, you can specify the certain branch name. Assume if you only want to build master branch, you can specify master branch in Get Source step (for manually build), or specify master branch in Branch filters (for CI build).
If you want to build multiple branches in a build definition (for CI build), you can specify the branches in branch filters on Triggers Tab.
If you want to verify a PR before merging, you can add build validation for branch policy.
For your concerns:
Even a build definition can trigger multiple branches, but for a certain build, it build a certain branch after changes are pushed on this branch. And you can detect which branch is actually build, and update branch version number correspondingly.
Such as you have a build definition which can trigger to build both for master branch and dev branch. After pushing changes to master branch, a build will be queued for master branch. And you can get the branch name by some ways, so you can increase the version number correspondingly.
You can not only specify which branches can be triggered in your build definition, but also specify the folders which can be triggered in path filters. Assume there are folderA and folderB both contain .sln, you want to trigger build only when the .sln file changes under folderA, so you can specify branch filters and path filters as below:
For the situation: multiple branches can be triggered by a build definition, you can add a PowerShell task to detect which branch is building. The script as below:
$head=$(git rev-parse HEAD)
$sha=$head.Substring(0,7)
$branches=$(git branch -rv)
for ($i=0;$i -lt $branches.Length; $i++)
{
if ($branches[$i] -match $sha)
{
$tbranch=$branches[$i] -split "\s+"
$local=$tbranch[1] -split '/'
$br=$local[1]
echo "You are building $br branch"
break
}
}

Answer 2

This part,
Is this a good idea? What are things to watch out for and the best ways to set this up?
is off-topic (too broad/primarily opinion based), so I'm ignoring it and answering the two concrete scenarios you outlined.
Not really sure what you're asking. Release definition environments can be set to trigger on branches (artifact triggers), so if you have different release requirements for older branches, you can have different release definitions or simply an alternate pipeline within a single release definition.
You can specify wildcards in the Visual Studio Build step so you can specify, for example, **/*.sln. That will find any .sln file under any folder.