Update GitVersion for large repositories

As you know I’m a fanatic user of GitVersion in builds, and I’ve written a simple task to use it in a TFS Build automatically. This is the typical task that you write and forget, because it just works and you usually not have the need to upgrade it. But there is a build where I start to see really high execution timing for the task, as an example GitVersion needs 2 minutes to run.


Figure 1: GitVersion task run time it is too high, 2 minutes

This behavior is perfectly reproducible on my local machine, that repository is quite big, it has lots of tags, feature branches and seems that GitFlow needs lot of time to determine semantic versioning.

Looking in the GitHub page of the project, I read some issue regarding performance problem, the good part is that all performance problem seems to disappear with the newer version, so it is time to upgrade the task.

Thanks to the new build system, updating a task in VSTS / TFS is really simple, I just deleted the old GitVersion executable and libraries from the folder where the task was defined, I copied over the new Gitversion.exe and libraries and with a tfx build tasks upload command I can immediately push the new version on my account.

Since I changed GitVersion from version 2 to version 3, it is a good practice to update the Major number of the task, to avoid all build to automatically use the new GitVersion executables, because it could break something. What I want is all build to show me that we have a new version of the task to use, so you can try and stick using the old version if Gitversion 3.6 gives you problems.

Whenever you do major change on a TFS / VSTS Build task it is a good practice to upgrade major number to avoid all builds to automatically use the new version of the task.

Thanks to versioning, you can decide if you want to try out the new version of the task for each distinct build.


Figure 2: Thanks to versioning the owner of the build can choose if  the build should be upgraded to use the new version of GitVersion task.

After upgrading the build just queue a new build and verify if the task runs fine and especially if the execution time is reduced.


Figure 3: New GitVersion executable have a real boost in performance.

With few minutes of work I upgraded my task and I’m able to use new version of GitVersion.exe in all the builds, reducing the execution time significantly. Comparing this with the old XAML build engine and you understand why you should migrate all of your XAML Build to the new Build System as soon as possible.

Gian Maria.

Development and Related Work missing on new UI form after upgrade to TFS 2017

I’ve dealt on How to enable the new work Item in TFS 2017, and you could have noticed some differences from Visual Studio Team Service Work Item layout, or even with new Team Projects created after the upgrade. In Figure 1 you can see in the left the detail of a PBI on a Team Project that exists before the upgrade to TFS 2017, in the right the PBI on a Team Project created after the upgrade.


Figure 1: Differencies of Work Item Form between Team Projects

This difference happens because the script that upgrade the Process Template to use the new form, does not add some part that are indeed present in newer Process Template. In the end you can be annoyed because new Team Project have different layout than existing ones. The solution is quite simple.

First of all install the Team Process Template Editor Extension for Visual Studio 2017, this will easy the process because will avoid resorting to command line. Now, as you can see in Figure 2, you should be able to use the menu Tools –> Process Editor –> Work Item Types that contains two commands: Import WIT and Export WIT.


Figure 2: Commands to import and export Work Item Definition of a Team Project directly inside VS

Process Template Editor will save you some command line details

With these two command you can export the definition of Work Items from a Team Project to your local disk (Export), then you can modify the definition and upload modified version to Team Project again (Import). If you choose Export, it will made you connect to a Project Collection, then choose the Team Project you want to use, and finally choose the Work Item Type, in my situation I’ve choose User Story Work Item Type and saved it to disk. When the export asks you to include the Global Definition List, please answer no.

It will be a good idea to save everything to a source controlled folder, so you can verify how you modified the Work Item Definition during the time.

After you downloaded the Work Item Definition of the Team Project you want to fix, Export the very same Work Item Definition, from a Team Project that was created after the upgrade to TFS 2017. It could be simpler instead to download the entire process template definition from the server and look for the Work Item Definition you need. Since I need to modify several Work Item Type definition, not only User Story, I decided to download the entire Process Template for the Agile definition


Figure 3: How to download an entire process template directly from Visual Studio.

The menu Team –> Team Project Collection Settings – > Process Template Manager will do the trick; this command will open a dialog with all the Process Template Definition and I simply grab the Agile (default) and download to a source controlled folder.

Now you should have two file User Story.xml, the first one of the TP that was upgraded (the one that missing the Development and Related Work UI Section) and the other is the one of the Process Template Definition, that contains the sections you miss.

You can just compare them with whatever tool you prefer. The result is that the two files usually are really different, but we do not care for now about all the differences, we can just scroll to the bottom to find the definition of the layout of the new UI as you can see in Figure 4.


Figure 4: Different UI definition section between existing and new Team Project

In the left we have Status and Planning section, while on the right we have planning and development, the two missing parts we want to see in our new Work Item Form Layout are instead on the new definition. Now you only need to adjust the layout on the left to make it include the missing two section. In Figure 5 is shown how I modified the file.


Figure 5: Modified Process template

You can rearrange the form as you like, as you can see I’ve made it equal to the one of the latest version of the Process Template, except that I left the Story Point in the Planning section.

Once you are done, you can use the Import WIT function from Visual Studio 2017 to upload the new definition to the Team Project you want to modify. If you made errors the Work Item Definition will not be imported, so you do not risk to damage anything.

If the import went OK, just refresh the page in the browser and you should immediately see the new layout in action, Development and Related Work section are now visible. You can also rearrange the UI if you like to move information in a way that are more suitable to your needs.

Now repeat the very same procedure for Features, Epics, Task and whatever Work Item Type that miss some section respect a newly created process template.

If you need to do this procedure for more than one Team Project, you need to repeat all the steps if the other Team Project is based on a different template (Agile, SCRUM, CMMI) or it contains different customization.

It is always a good procedure to always export the actual definition of a Work Item before starting to modify it, to avoid messing up the template.

If you did a good work and stored all customization into source control, you still need to export the definition from the template, to verify if the definition was changed from the latest time you modified it. Even if you are sure that the latest customizations are in source control, remember that when you upgrade TFS it could be possible that Process Template Definition was upgraded to enable new features (as for the new Work Item Layout Form).

Gian Maria Ricci

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