Action required for a VSTS Extension

It could happen that you received an Email from VSTS telling you that one of the extension needs some action.


Figure 1: An email telling you that an extension needs action to be updated.

If you go to your account and check the extension page, you find a situation like this one.


Figure 2: Extension is listed in the “action required” section

You could be puzzled, because there is warning icon, but no indication on what you need to do to solve the situation, nor what the problem is. In this situation, the email states that the extension needs to be upgraded, but whatever problem you have, you need to check the menu related to the extension.


Figure 3: The extensions that needs action have an additional menù called Review

From Figure 3 you can see that the extension has a new menu entry called “Review”, that open the dialog shown in Figure 4.


Figure 4: Review dialog that explain what happened

Thanks to this dialog we can finally understand why the extension needs action, there is a new version, but the permissions required by this new version are different from the original one, so it needs an explicit intervention of an administrator to update. After all we do not want auto update of an extension being automatically able to give more permission to the extension.

Gian Maria.

The new Build editor in VSTS

In the latest update of VSTS a new build editor was rolled out and it is now available in your account. This is a preview of the new build editor and this imply that it is not immediately available, but you need to activate it for your user. You can find the button to enable it in the build hub


Figure 1: New build editor can be activated within the UI

The UI uses a Toggle Button, so you can disable it whenever you want if you do not like the new editor, or if you want to use the old one.

If you want to have a peek on all the preview features that are available and enabled for your user, you can simply use the “Preview Features” menu that is available on your user menu.


Figure 2: Preview features menu

In this new UI you can see all the new features and the activation status for your user.


Figure 3: All the preview features are shown in the Preview Features menu.

If you are the owner of the account, you can also manage the Preview Features that are available for the entire account.


Figure 4: Preview features for the entire account

As you can see in Figure 4 you can activate the new account landing page and Out of the box notification for the entire account, but the new build editor is not available, because it can be activated only by each user.

This new way to roll out new feature in VSTS is really interesting, because it allows for adminsitrators to test and try new features before they are rolled out to the team. This will allow for adequate preparation to be sure that all members of the team will be fully operative with the new features and it reduces the “who moved my cheese” syndrome.

Gian Maria.

Task versioning for TFS / VSTS Build

The build system of TFS / VSTS, introduced with TFS 2015, is evolving quite fast and release after release is always full of interesting new features. One of my favorites is the simple extention point to write a custom task to perform custom operation. The whole process is really simple and is described in this post.

One of the major problem when you manage a task is versioning, because you can have lots of builds using that task and if an update require to break the compatibility with the past, releasing a new version can really be a nightmare of many broken build.

Whenever you update a build task, there are many builds that are using it and if you introduce breaking changes, you risk to break all the builds that are using that task.

This is not a problem in VSTS / TFS, because a nice versionig control is in place; if you open a build you can find a flag near some build tasks.


Figure 1: Alerting on task that warn you about a new version of the task.

In Figure 1 you can find that a purple flag is telling you that you are using an old version of the task and that there are newer version available. This happens because a major version is available, but to preserve compatibility, existing build still uses the old version. 

If you look at task detail you can choose the version to use, as shown in Figure 2


Figure 2: Choose version of task to use in the build

As you can see, you do not need to select an exact version, instead you can choose only the MAJOR version of the task, according to Semver. This logic follows semantic versioning, that states: whenever a breaking changes occurs, you need to change Major number. TFS / VSTS Build system assumes that a task, until a major version is not changes, is fully compatibile so it always uses the most recent version of that major.

When upgrading your custom task, update the major number if you are introducing breaking changes, this will prevent existing build to automatically use the new version.

This works not only with built-in tasks, but the same method works for any task, so, whenever you need to introduce some breaking changes in your custom build task, be sure to increment the major version. This will prevent existing build to use the new version, so you can upload the task in your account without problem. Once the new version is uploaded you can migrate each build without the risk of a big bang upgrade.

Also, if you find bug in an older version, you can still increment minor or patch number to fix task for all build that still uses old version. If you are at version 3.x.x but some builds still uses 2.x.x, if you need to fix a bug in that version you can simply patch version 2.x.x, assign number 2.x.x+1 (increment patch) and then upload the task.

Due to TFS /VSTS task versioning, I strongly suggests you to use GitFlow to develop your task, so it is easy for you to patch older version if needed.

If you include release notes in task.json you will also give the user information on what was changed.


Figure 3: Task.json file with release notes

Release notes are shown in the Build ui when you select specific version, and this can be used to give details on what is changed to explain why the major version is changed.


Figure 4: Release notes for the task are shown on the UI during build edit.

Version checking will really made management of build task a breeze.

Happy TFS / VSTS.

Gian Maria

Bash pornography

Suppose you have two Git repositories that are in sync with a VSTS build, after some time the usual problem is that, branches that are deleted from the “main” repository are not deleted from mirrored repository.

The reason is, whenever someone does a push on main repository, VSTS build push the branch to the other repository, but when someone deleted a branch, there is no build triggered, so the mirrored repository still maintain all branches.

This is usually not a big problem, I can accept that cloned repository still maintain deleted branches for some time after a branch is deleted from the original repository and I can accept that this kind of cleanup could be scheduled or done manually periodically. My question is:

In a git repository with two remotes configured, how can I delete branch in remote B that are not present in remote A?

I am pretty sure that there are lots of possible solutions using node.js or PowerShell or other scripting language. After all we are programmer and it is quite simple to issue a git branch –r command, parsing the output to determine branches in repository B that are not in repository A, then issue a git push remote –delete command.

Since I use git with Bash even in Windows, I really prefer a single line bash instruction that can do everything for me.

The solution is this command and I must admit that it is some sort of Bash Pornography :D.

diff --suppress-common-lines <(git branch -r | grep origin/ | sed 1d | sed "s/origin\///")  " | sed "s/>\s*//" | xargs git push --delete vsts

This is some sort of unreadble line, but it works. It is also not really complex, you only need to consider the basic constituent, first of all I use the diff command to diff two input stream. The general syntax is diff <(1) <(2) where 1 and 2 are output of a bash command. In the above example (1) is:

(git branch -r | grep origin/ | sed 1d | sed "s/origin\///")

This command list all the branches, then keep only lines that start with origin/ (grep origin/ ), then removes the first line (sed 1d) because it contains origin HEAD pointer, and finally remove the trailing origin/ from each line (sed “s/origin\///”). If I run this I got something like this.


Figure 1: Output of the command to list all branches in a remote

This is a simple list of all branches that are present on remote origin. If you look at the big command line, you can notice that the diff instruction diffs the output of this command and another identical command that is used to list branches in VSTS.

The output of the diff command is one line for each branch that is in VSTS and it is not in origin, so you can pipe this list to xargs, to issue a push –delete for each branch.

Now you can use this command simply issuing a git fetch for each remotes, then paste the instruction in your bash, press return and the game is done.


Figure 2: Results of the command, two branches are deleted from VSTS remote because they were deleted from the origin remote

It is amazing what you can do with bash + awk + sed in a single line 😛

Gian Maria.

One reason to upgrade to TFS 2017: Code search

I always suggest teams to use VSTS instead of on-premise TFS. The main reason is avoiding any issue with administration or upgrades. In these years, one of the main risk of having TFS on-premise is not planning for upgrade and keeping the first version installed for years. As a result, it is not uncommon to have teams that still uses TFS 2013 even if version 2017 is out.

For small teams usually there is not a dedicated TFS administrator; in this situation is it strongly advisable not to skip one entire major upgrade, to minimize the risk of a big bang upgrade. Suppose you have TFS 2015, I strongly suggest you to upgrade to TFS 2017, before another major version is out. This will prevent to have to upgrade 2 or more major version, with the risk of long upgrade times and too many changed that could makes the user upset.

As a general rule, if you need to use on-premise TFS, you should upgrade as frequently as possible and never skip one major upgrade.

If you are not sure that upgrading to TFS 2017 worths the time needed to plan an perform the upgrade, I’d like to share with you some of the new exciting new features.

My favorite feature of TFS 2017 is Code Search, that allows to perform semantic searches within code.

Every developer loves experimenting new libraries, new patterns etc, and in the long run Hard Disks of people in the team is full of small little projects. One day you remember that someone wrote a Proof of concepts to test bulk load with ElasticSearch but you do not know how to find the code. The obvious solution is storing everything inside your TFS (VSTS), using Git or TFVC, then search code with this new exciting functionality.

In TFS 2017 you have the “Search code” textbox, in the left upper part of the Web UI, and if you start typing a nice help allows you to view the syntax you can use.


Figure 1: All the syntax used to search inside code with the new Search Code Functionality

As you can see you can search text inside name of a class, comment, constructor, etc, and you can also use AND OR NOT. This gives you a tremendous flexibility and usually in few seconds you can can find the code you need. Results are presented in a nice way, and you can immediately jump to the code to verify if the result is really what you are searching for.


Figure 2: Results allows you to immediately browse the file with the match within the Web Ui

If you still are in TFS 2015 or earlier version, I strongly suggest you to plan for an upgrade to 2017, to use this new exciting feature.

Gian Maria.