Changing TFVC Repository Mappings can break your build unexpectedly

Recently I encountered a suddenly broken TFS build. The process says we build hotfixes through a shelveset first to be able to test them properly before releasing them, and avoid possible conflicts with other fires. The developer in question tackled the bug at hand and created the shelveset, then continued to go ahead and build it. We have a Hotfix build definition available but the TFVC source mapping had to be updated while it was not pointing to the correct branch.
This screen below shows the current source mappings, and for this build to work he had to bump the branch version (v2.15 to v2.16).

Build Settings

When queueing the build including the shelveset it all came to a halt. The build actually failed on the first step [Get Sources] which was unexpected.

The trace

What actually happens here can be explained by looking at the build log;
Build Log

At line 3 it starts undoing any locally available edits, in this case it finds changed assemblyinfo.cs files of a previous build. Nothing wrong with undoing these (agent local) edits.
At line 6 it indicates it will delete any files that do not exist in the local version table. This also includes previously generated build output. Also fine.
Then in line 13/14 it says to get the workspace, and unshelve the desired changeset. And then is goes “boom”.

What is the problem?

The problem is that cleaning process is thorough but, I changed the source branch, and that is not being reflected in this process. So after the cleaning process I have the cleaned sources of Branch v2.15 while I actually need Branch v2.16.

How to work around this situation?

There are a few solutions, the ultimate solution is to have a fresh build agent every time, then you will never run into these errors. This can be done using a hosted build controller. In my current on-premise scenario this is not the most ideal scenario.
Another would be to have an on-premise auto re-provision of an agent but that seems a bit far-fetched too.
An easier solution that will always work is to use a slightly different source mapping from the beginning as can be seen in the image below.

Build Settings Changes

The effect of this change is that the agent will clean v2.15, then delete files, then get v2.16 because this directory does not exist yet, then will unshelve the shelveset and build it with success. Minor downside to this is that the [Get Sources] (cleaning process) takes a bit longer when changing branches. In the log below this can be checked.

Build Log After

Combining TFS Version Control and Git with Git-TF

Great post on utilizing the power of Git in combination with Team Foundation Version Control

The Road to ALM

For a customer I am (together with my colleague Jasper Gilhuis) setting up a hybrid solution regarding Version Control. Some Scrum teams use Git as their primary Source Control system and most of them use TFS Version Control.

What we see at different organizations is that it requires the teams to check-in all code on a TFS branch. Most of the times this is needed to facilitate the release process or to facilitate auditors. However, some teams do not like to work with TFS Version Control or cannot work with TFS Version Control (e.g. XCode developers. What happens is that teams maintain duplicate repositories. The “Git” teams set up a TFS workspace and a Git Repository. All the work is done in the Git repository and when the work is done, the files are copied to the TFS workspace.

This works quite well, but traceability is hard. Git teams…

View original post 618 more words