TFS - build definition with frequently changing branch path - tfs

Question

My team uses a per-release and per-sprint branching approach. So we typically have a fresh branch off of Main (integration) for the current sprint and a branch off of Main for each release.
Main Branch
|
-- Development Folder
| |
| -- Sprint 2.10_1 Branch
| -- Sprint 2.10_2 Branch *current*
|
-- Release Folder
| |
| -- Release 2.8.0 Branch
| -- Release 2.9.0 Branch *current*
There are two build definitions. One points at the current dev branch and the other points at the current release branch.
This setup is working well, except that it has become a bit time-consuming and error-prone to update all the branch paths in the builds every time we branch for a new sprint and branch for a new release. Each build has branch paths in these places:
Source Settings > source control folders (multiple active and cloaked paths)
Process parameters > Build > projects to build (paths to multiple
projects)
A build only ever points to one branch location in tfs, and the only part of that branch path that changes each time is the number associated with the current sprint or release. So for instance a build might switch from pointing from /developement/2.10_1/ to /developement/2.10_2/.
Is there a way to define a base-path once in your build definition and then use it throughout the definition? That way each time we switch branches we only have to specify the branch path in one place? Even better, could that variable's value be managed outside of the build definition so that it could be used by several build definitions? Could the variable value possibly be dynamic based on the active Iteration for the project?
Or can the path entries in the build definition be defined in such a way that they are relative to the branch?
Any suggestions? Thanks!

Answer 1

I've set up our builds so that they use a custom $(BranchToBuild) parameter which is inserted into all the build paths within the build. This eliminates the problem you have in the 'projects to build' section of the definition.
This parameter can then be passed into the build by adding a /p:BranchToBuild=2.10_2 to the build parameters in the Queue Build dialog, so you can manually select any branch to build from with every build you queue up.
You can also set the default parameters within your build definition so that it defaults to /p:BranchToBuild=2.10_2 for every build - each time you make a new branch the "current" one you can just change this default and all subsequent builds will automatically use the correct branch (but you can still go back and do a build off any previous branch easily, for example if you have to merge a bug fix back into a previous release)
The only hassle with this is (as you've spotted) that you have to also map the code for the branch onto the build server for it to be got from source control. There is a shortcut for this though - in the build definition, select all the mappings for your old branch (10.1_1) and copy them. Paste into a text editor and you'll see that each just becomes a simple line of text. Now you can globally search and replace 10.1_1 with 10.1_2, then copy and paste the entire set of mappings back to the build definition. Miles faster and less error prone than manually editing every line in the mappings.
All the above means that setting up a new branch takes me about 30 seconds.
The caveat is that the build definition points at the vcproj file that controls the build, and it gets this file before it runs the build itself. It is therefore problematic to put your build definition inside the branch. Generally this is not a problem, but occasionally when you need to update the build definition it can therefore break your branches unless you also manually point the build definition at the correct variant of the vcproj. Generally I get around this by avoiding breaking changes in the build, so it has only bitten me once in the last 7 years.