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

image

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.

image

Figure 2: Preview features menu

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

image

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.

image

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.

image

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

SNAGHTMLf0c767

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.

image

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.

image

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

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.

clip_image001

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.

clip_image002

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.

Building with agent without Visual Studio installed

I had a build that runs fine on some agents, then I try running the build on a different agent but the build failed with the error.

Error MSB4019: The imported project “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets” was not found

The problem originated by the fact that the build was configured to compile with VS2015 and use VS2015 test runner, but in build machine the only version of Visual Studio installed is VS2013.

For various reason I do not want to install VS 2015 on that build agent, so I tried to manually configure the agent to have my build and my unit tests running without the need of a full VS 2015 installation.

Warning: this technique worked for my build, but I cannot assure that it would work for your build.

Step 1: Install MSbuild 14 and targets

First of all I’ve installed Microsoft Build tools 2015 to have the very same version of MSBuild that VS2015 uses, but this not enough, because the build still complains that it was unable to find Microsoft.WebApplication.targets. The solution was copying the entire directory C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0 from my developer machine (where everything compiles perfectly) to the very same directory of my build server.

This solution usually works, because you are actually do a manual copy of all .targets that are needed by MsBuild to compile the solution (Asp.Net, etc etc). Now the source code compiles, but I’ve an error during test execution.

Step 2: Execute test with Visual Studio Test runner

Now the Test action failed with this error

System.IO.FileNotFoundException: Unable to determine the location of vstest.console.exe

Since I’ve not installed Visual Studio 2015 test runner is missing and tests could not execute.  To solve this problem I’ve installed Visual Studio 2015 agents, but the error is still there, even if I checked that the test runner was correctly installed. After some googling I’ve discovered that I need to modify a Registry Key called HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0 adding a simple string value named ShellFolder that points to the standard Visual Studio directory: C:\Program Files (x86)\Microsoft Visual Studio 14.0\

image

Figure 1: New registry key needed to the build agent to locate test runner.

After this last modification the solution builds and all test runs perfectly without VS 2015 installed on the build machine.

Please remember that this solution could not work for your environment.  The official and suggestged solution is installing to the build agents all versions of Visual Studio you need to bulid your code.

Gian Maria

Enable new Work Item Form in TFS “15”

If you installed TFS 15 Preview, one of the news you expected to see is the new Work Item Layout (already available in VSTS). You could get disappointed that actually your existing Work Items still are shown with the old interface, as you can see in Figure 1

image

Figure 1: After upgrade TFS still shows the old Work Item Form

The new Work Item Form is installed with an opt-in method so it is disabled by default. To enable it you should navigate to the Project Collection administration page. From here you should see that this feature is actually disabled (Figure 2), but you have the link to Enable it.

image

Figure 2: New Work Item form is disabled by default after upgrade

If you click the “Enable the new work item form” link, you are informed that this operation will create a new layout for the Work Item, but you can choose, after the creation of the new layout, if you want to use the new model, and the opt-in model, as you can see in Figure 3.

image

Figure 3: Enabling the new Work Item layout starts with the creation of the new Layout.

Thanks to the opt-in method, you are not forced to use the new layout, but you can activate it only if you want to use it

After the creation of the Layout you should configure the Opt-in model, or you can disable entirely the new Work Item Form.

image

Figure 4: Options to enable the new Work Item form with the opt-in model

The opt-in model basically allows you to decide who can view the new Work Item form layout. You have three options, as shown in Figure 5, you can give the ability to use the new layout only to administrators, to all user, or you can force everyone to use the new Layout, disabling the old layout entirely.

image

Figure 5: Opt-in model options to enable the new Layout form

Opt-in model for the new Layout Form is really flexible because you can leave the decision up to each single user.

The central option is usually the less impacting, because each member of the team can choose to evaluate the new layout or stick with the old one. A new link appears on the head of the Work Item Form, in the far right part, as you can see in Figure 6.

image

Figure 6: Opt in model allows each user to choose to evaluate the new form.

If the user choose to preview the new form, the page refresh and the Work Item is rendered with the new layout. The user has the option to return to the old form if he do not like the new form, giving the whole team the time to evaluate the feature and decide if using it or not.

SNAGHTML7928e8

Figure 8: New form is active and the user can back to old form if the do not like it.

This settings is “per collection” so you can decide different opt-in model for each collection of your TFS.

Gian Maria.