VSTS / TFS: use Wildcards for continuous integration in Git

If you setup a build in VSTS / TFS against a git repository, you can choose to trigger the build when some specific branch changed. You can press plus button and a nice combobox appears to select the branch you want to monitor.


Figure 1: Adding a branch as trigger in VSTS / TFS Build

This means that if you add feature/1312_languageSelector, each time a new commit will be pushed on that branch, a new build will trigger. Actually if you use GitFlow you are interested in building each feature branch, so you do not want to add every feature branch in the list of monitored branches.

If you look closely, it turns out that the combo you use to choose branches admit wildcards. If you look at Figure 2, you can verify that, pressing the add button, a new line is added and you have a textbox that allow you to “Filter my branches”.


Figure 2: Filter branch text

Actually the name is misleading, because you can simply write feature/* and press enter, to instruct VSTS to monitor each branch that starts with feature/.

Using wildcards in trigger list allows you to trigger a build for every feature branch.

For people not used to VSTS, this feature goes often unnoticed, because they think that the textbox can be used only to filter one branch. With this technique you can trigger a build for each change in each standard branch in GitFlow process.


Figure 3: Trigger with wildcards

As you can see in Figure 3, I instructed TFS / VSTS to build develop, master and all hotfix, feature or release branches.

Gian Maria

New cool feature of VSTS to limit impact of erratic tests

I’ve blogged some time ago about running UAT testing with a mix of Build + Release in VSTS. Actually, UAT testing are often hard to write, because they can be erratic. As an example, we have a software composed by 5 services that collaborates together, CQRS and Event Sourcing, so most of the tests are based on a typical pattern: Do something then wait for something to happen.

Writing tests that interact with the UI or are based on several services interacting togheter can be difficult.

The problem is: whenever you are “wait for something to happen” you are evoking dragons. Actually we wrote a lot of extensions that helps writing tests, such as WaitForReadModel, that poll the readmodel waiting for the final result of a command, but sometimes those kind of tests are not stable because during a full run, some tests are slower or simply they fails because some other tests changed some precondition.

We spent time to make test stable, but some tests tend to have erratic failure and you cannot spent tons of time to avoid this. When they fails in VS or Nunit console, you can simply re-run again only failed tests and usually they pass without a single error. This is perfectly fine when you are running everything manually, you launch tests in a VM, then come back after a little bit, if some tests failed, just re-run failed test and verify if something was really broken.

Erratic tests are really difficult to handle in a build, because if the build was always red because of them, the team tend to ignore build output.

When a build is often failing due to false-positive, team tend to ignore that build and it starts losing value.

Thanks to a cool new feature in VSTS, we can instruct our builds to re-run automatically those kind of tests. You can read everything about it in the release notes for VSTS.


Figure 1: Option to re-run failed tests

It could seem a little feature, especially because usually your tests should not be erratic, but actually it is a HUGE feature for UAT testing, when having not erratic test is simply not feasible or a really huge work. Thanks to this feature, the build can automatically re-run failed tests, completely eliminating the problem of erratic tests, and showing as failed only tests that really failed constantly for more than a given amount of runs.

Another situation where this feature has tremendous impact is when you want to  migrate a huge set of tests from sequential execution to parallel execution. If your test were written assuming sequential execution, when you run them in parallel you will have many failures due to interacting tests. You can simply create a build, enable parallel execution and enable re-run failed test. This will simply helps you to spot interacting tests so you can start fixing them so they can run in parallel.

If you look at Figure 2, you can verify that all erratic tests are easily identified, because you can filter all tests that passed on rerun. This will leave your build green, but can spot erratic tests that should be investigated to make them more stable.


Figure 2: Erratic test can be immediately discovered from build output.

I think that this feature is really huge and can tremendously helps running UAT and Integration tests in build and releases.

If you do not see the option in figure 1, please be sure you are actually using the version number 2 of the test runner task as shown in Figure 3.


Figure 3: Be sure to use version 2.* of the test runner, or the option to re-run failed test is not present.

Gian Maria.

VSTS Package, packages failed to publish

I have a build that publishes nuget packages on MyGet, we decided to move packages to VSTS internal package management, so I simply added another Build Task that pushes packages to VSTS internal feed. Sadly enough I got a really generic error

Error: An unexpected error occurred while trying to push the package with VstsNuGetPush.exe.
Packages failed to publish

Those two errors does not gives me real information on what went wrong, but looking in the whole log, I verified that the error happens when the task was trying to publish symbols packages (2).


Figure 1: Complete error log

It turns out that VSTS Package management is not still capable of publishing symbols package and this generates the error.

To solve this problem you can avoid generating symbols package, or you can simply avoid pushing them to VSTS feed. In the future VSTS feeds will probably supports symbols package and this problem will be gone.

In the meanwhile we have a issue on GitHub where we asked to the team for a much clearer error message, that can immediately point out the problem during the push.

Gian Maria.

Migrate your TFS to VSTS

I’ve discussed a lot with many customers over the benefit of VSTS over TFS, especially for small companies, where there is no budget for a dedicated TFS administrator. The usual risk is not updating TFS, loosing the update train and then have a problem doing upgrades like TFS 2008 to TFS 2017.

For those realities, adopting VSTS is a huge benefit, no administration costs, no hardware costs, automatic upgrade, accessible from everywhere, same licensing (license for VSTS are also valid for TFS) and much more.  Also one of the original limitation, the inability to customize process, is now gone and, for certain aspect, VSTS is superior to the on-premise version (in VSTS you can do less customization but everything is done with Web Interface without needs to edit XML process file)

If you are a small company, VSTS is the perfect tool, it contains everything for DevOps, zero maintenance cost, extensible and free for the first 5 users.

To perform the migration Microsoft released a dedicated tool to do a complete migration, you can find details here https://www.visualstudio.com/team-services/migrate-tfs-vsts/ the process is well documented, with a dedicated step by step guide.


Figure 1: Step by step migration guide download.

Please read the guide carefully and verify the required version for TFS to being able to migrate. As you see from Figure 1 you can migrate from TFS 2017 update2, TFS 2017 Update 3 and TFS 2018 RTW. Please notice that you cannot use a migrator tool on a TFS version different from the version declared by the tool. The tool will be updated to reflect and support the new version of TFS, and it will support only the most recent versions. If you have an old TFS instance, the suggestion is to migrate as soon as possible, then plan for the migration.

If you need support, check one of the official DevOps partner at this address http://devopsms.com/SearchVSTSPartner, they can support your company for a smooth and successful migration, especially if you are a large organization and have a big TFS instance.

Gian Maria

Converting regular build in YAML build

YAML build in VSTS / TFS is one of the most welcomed feature in the Continuous Integration engine, because it really opens many new possibilities. Two of the most important advantages you have with this approach are: build definitions will follow branches, so each branch can have a different definition, then, since the build is in the code, everything is audited, you can pull request build modification and you can test different build in branches as you do with code.

Given that build definition in code is a HUGE steps forward, especially for people with strong DevOps attitude, the common question is: how can I convert all of my existing builds in YAML Build?

Edit: This is the nice aspect of VSTS, it moves really forward, I’ve prepared this post while this feature was in preview, and converting was a little bit of effort, now converting a build is really simple, you have a nice View YAML Button during build edit.


Figure 1: YAML definition of an existing build can be seen directly from build editing.

This button will open the corresponding YAML build definition for current build, thus making straightforward to convert existing builds.

This is VSTS, it moves forwards so fast 🙂 and if you want to do a post about a Preview Feature, often you should be really quick, before new functionalities makes the post old.

Old Way (before the View YAML)

While the feature was in early preview, converting is more manual,  we did not have an automatic tool that does this, but if you got a little bit of patience, the operation wasnot so complex.

First of all the engine of the YAML build is the very same of standard build, only the syntax is different, thus, every standard build can be converted in YAML build, you only need to understand the right syntax. This is how I proceeded to convert a definition.

First Step: Install an agent in your local machine, it is a matter of minutes, then delete everything in the _work folder and finally schedule a build with agent.name request equal to the name of the agent. This will schedule the regular build in your machine, and in the _work folder you will have a subfolder _tasks that contains all the definition of all the tasks used in your build. This will greatly simplify finding name and version of task used in your build, because you can easily open the folder with Visual Studio Code and you can browse everything.


Figure 2: List of tasks downloaded by the agent to execute the build. 

Then you can simply move to the History tab of the original build, where you can choose to “Compare Difference” so you can easily view the json definition of the build, where you can find all the parameters of the task and the value in the build in a Super Easy way.


Figure 3: Thanks to the Compare difference you can quickly have a look at the actual definition and all the parameters.


Figure 4: All tasks parameters are included in the definition and can be used to generate YAML build file.

Happy building.

Gian Maria.