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.

At my current gig, we use TFS 2018 for all of our continuous delivery needs. Coming from a TeamCity and Octopus Deploy background, I wanted a way to build and release all of our git feature branches as we work on them. This is simple to set up in Team Foundation Server (and Visual Studio Team Services), although the UI is far from intuitive.

The benefit of this process is that we automatically build the source code (in both debug and release modes), run all the tests and deploy the result - for all branches - before we merge Pull Requests. This catches issues earlier, before they affect others. These could be problems with database update scripts or missing dependencies in release build configurations.

We currently use this for a TypeScript Angular app and related C# .NET JSON API and it has been very helpful. However, this approach offers advantages for almost all projects.

How To

Here is how to build and release all branches in TFS 2018 and VSTS. You can adapt it to only work for a subset of branches if you would like.

Step 1

First of all you need to set up a trigger for a build on your git repository. Enable the Continuous Integration trigger and in the branch dropdown type a wildcard and press enter. It’s not obvious that you can do this but it does work. In the following image I have entered * so that all branches will trigger a build.

Just press enter and the wildcard will be set.

Step 2

There is no step two, that’s it. Although, it is not at all clear from the UI. In the “Get sources” task it will still say master, but that is not the branch that will be used. The branch that triggered the build is the one that will be used.

Now you can simply set up a release triggered from the build and all successful builds with tests passing will be released. Or you could just create the release and keep the deployment as a manual or scheduled trigger.

Future Improvements

Apart from improving the UI it would be nice if the workflow could be more PR based rather than branch based. Ideally I would like builds only when a PR is created and to use the result of the merge as the source. When a PR is merged then all others should be rebuilt and fail if there are merge conflicts. I’ve previously set up a system that worked this way using GitHub, TeamCity and Octopus, and it worked really well.

We use PRs for code reviews but we don’t merge them until the feature has passed test. TFS has a nice feature where you can approve a PR (as a code review) without merging it, which is another distinct step.

Alerts Tool

All this CI/CD is great, but it’s worthless if you don’t notice the failures. Emails can be easy to ignore when you get a lot.

With the upgrade to TFS 2018, XAML builds have been deprecated. This is good news, but the build notifications tool that used to ship with VS only supports XAML builds (using a WCF API, yuck). The new TFS 2015+ releases are much better (and the UI has changed in 2018) but they use nicer REST APIs and the tool has not been updated. Also, TFS/VSTS is one of the only CI systems to not support the de-facto CC Tray XML standard.

To this end, I’ve created a system tray notification tool for new TFS/VSTS builds/releases that also integrates with our chat system. Let me know if publishing this would be of interest.

I’ve also made a more engaging alert system that hooks into our motorised desks, but I’ll save that for another post. 😀