Who moved my chees, but now it is in a better place

I’m not a great fan when software I used everyday change position of stuffs, especially when main menu / navigation system changes. This is a problem generally known as “who moved my cheese” and lead to small frustration because you need to find where your everyday options were moved. Recently VSTS changed navigation system, from an horizontal menu to a vertical menu, rearranging the whole navigation, my cheese was moved, but this time for better.

I need to admit that new navigation is really better and even if you need time to become familiar with it, everything seems more rationally placed. As an example it finally overcome one of the main pain point of the older navigation system, configuration for area and iteration between Team Project and Teams.

In the classic navigation system of VSTS, it is not so easy to understand where you need to click to configure Area and Iteration for Project and Teams.

One of the main pain point was that you need to create iteration and areas in Team Configuration, then you need to assign to each Team. Novice users quite often get lost in the menu system and needs to be guided where the things are. So lets start exploring how you manage team with the new vertical menu.

With the new navigation, when you enter configuration for your Team Project, you have a nice node called Teams (1) where you can immediately view the list of the Teams as well as the team that was tagged as default.


Figure 1: Team Configuration menu in the new navigation system

Details page are the same, but the new navigation system is more clear and team management is more prominent.

In the new navigation system, team management is more discoverable.

Another source of confusion was configuration for Area and Iteration between the entire Team Project and single team. In almost all the course I did, people gets a little lost with the old navigation system and needs some time to accomplish simple task, like creating new iteration in Team Project then add those iteration to team.


Figure 2: Configuration of iterations and areas in new navigation system

As you can see in Figure 2, when you choose configuration for Work (1) you now have two clear choices, Project configuration or Team Configuration (2), finally all confusion is gone away. If you choose Project configuration you can manage iterations and areas for the entire team (3), this is the place where you creates iterations and areas for the project.

If you instead choose Team Configuration (Figure 2), you have a top level breadcrumb (2) that can be used to switch between teams, and for each team you have the classic menu (3) used to configure General / Iterations / Areas / Templates.


Figure 3: Configuration for Work related to teams

This is really better than the old navigation menu, because you always know if you are configuring the entire project or single team and the ability to switch between team configuration directly with the breadcrumb is a really welcomed feature, as shown in Figure 4.


Figure 4: Changing team in configuration is now possible with the breadcrumb.

If you are still using old menu, I strongly suggest you to enable this new feature with the usual “Preview features” menu available in the personal menu (right upper part where your avatar is shown.


Figure 5: Use the Preview Features menu to enable the new navigation.

Even if the new navigation menu is in preview, I strongly suggest you to enable it, because it will simplify your everyday work in VSTS.

Gian Maria

Converting PowerShell Task in YAML

YAML Builds have many advantages over traditional build definitions, especially because YAML build definitions follows branching of code, a killer feature that is fantastic if you use GitFlow.

YAML Build definitions are stored in code, this allows them to follow branches, minimizing the need to maintain builds that should build code in different moment in time.

As an example I have a build where I have tasks to publish some Web Sites, if I had a new Web Site to publish, I can add another task in YAML build, but the build still work for older branches, especially for the master branch that represent my code in production.

To minimize impacts, I tend to use PowerShell scripts stored inside code repository to perform build tasks, this was an old trick  useful when YAML build was not present. Scripts allows you to create a generic build, add some tasks to run PowerShell scripts, and the result is that scripts follow branches.

Now that YAML Build is available, I started converting everything to YAML build, a task that is made simple tanks to a nice feature of VSTS, in the UI there is a nice View YAML button that convert all of my build definition with new YAML syntax.


Figure 1: Ui functionality to show the current standard build definition translated to new YAML build definition.

As you can see from Figure 1, PowerShell tasks is not converted as a task, but with a node of type powershell, followed by parameters. This is perfectly valid, because YAML build can contain a powershell node, but in my specific situation the build failed, because the conversion failed to setup working directory.

Even if YAML build allows direct call of PowerShell scripts, if you convert a working build that uses PowerShell task it is better to use the same Task inside YAML definition.

To solve my problem I simply changed generated YAML build definition to use a standard PowerShell task, this is the declaration of the task.

- task: PowerShell@2
  displayName: Pack Release
    targetType: filePath
    filePath: 'tools\packrelease.ps1'
    arguments: '-Configuration $(BuildConfiguration) -DestinationDir $(Build.ArtifactStagingDirectory) -StandardZipFormat $false -SkipZip $false -SkipConfigRename $false -compressionLevel 5'
    workingDirectory: 'tools'

As usual you specify a task and the type, in this example PowerShell@2. It is important the version after the @ character, it should be equal to the version of the task in the standard build, as shown in Figure 2.


Figure 2: Pay attention to version Task when you convert to YAML build.

To know input parameter name of the tasks (Es. targetType, arguments, workingDirectory, etc), the most immediate solution is looking in the working directory of an agent and find the task definition.


Figure 3: Tasks inside working folder of an agent.

Inside the folder of the chosen task there are all latest version for any major version, and inside each version folder there is a task.json file that can be inspected to know the exact version of the parameter.

After modifying YAML build to use PowerShell task the build started working as usual.

Gian Maria.

Creating a Wiki with code in VSTS

Information spread is one of the key of success for Agile Teams, the ability to quick find information about a project, definition of UBIQUITOUS LANGUAGE and everything that can be related to the project should be prominent for each member of the project. In this scenario, the information should also be near where it need to be, but at the same time it should be widely available to every member of the team.

There are some concepts, like UBIQUITOUS LANGUAGE that should be near the code (name of classes should adhere to the UBIQUITOUS LANGUAGE) but at the same time we want that kind of information to be widely available. There are also other type of information that should be near to code, like guidelines, instruction on how to start working with a project etc, but that kind of information should be available even outside the code.

Where to place information is a really though decision, putting information in Code made it near to where it need to be used, but it can be less discoverable and usable

Luckily enough VSTS has a really good solution for this scenario, Wiki that are stored inside a repository. You can in fact use any folder of any Git Repository and starting creating a Wiki in Markdown, commit files, and then have VSTS render them as Wiki in the appropriate section. This has the double advantage of having information into the code, but at the same time the information is available via web wiki.

Yes, you could browse markdonw files directly from code repository since long time in the past, but having it converted to wiki is a major advantage, because readers does not need to know how to browse code. Here is an example how a readme.md looks like in the code repository


Image 1: Browsing of Markdown file directly in code browser

As you can see, markdown files inside code repository can be rendered without problem inside VSTS Code browsing. This is ok, but the information is not discoverable and it is not 100% friendly.

Forcing people to find information browsing in the Code section of VSTS is acceptable for developers, but not for other member of the team

Here are the problem: first you need to go to Code Browsing, then you need to choose a repository, know that the wiki is in a specific path (ok if you use wiki folder it is obvious 🙂 ) and lastly you are browsing information in the context of a repository (you have the tree at the left etc. Another annoying problem is that you should understand which branch to use to browse the most up-to-date and correct version of the wiki, Ex: is the Master or Develop branch that contains the most correct and reviewed version of the wiki?

If you go on the Overview section of the team project and navigate in the Wiki Section you have the option of publishing code as wiki. As you can see in Figure 2, it is just a matter of specifying to VSTS repository, branch, path and name of the wiki.


Figure 2: Publish part of a repository as wiki

Once the wiki is published it is more discoverable, because it is listed in the apposite section of the menu and it has a specific name, that is not related to the repository.


Figure 3: Code published as wiki

As you can see from Figure 3, you have several advantages, first of all everyone can simply open Wiki section and find the information, wiki is rendered outside the context of a code browsing, and you can list all the wiki available for this project with a simple selector (2). The most interesting fact is that the real wiki is implemented as code in a folder of a Git Repository and can evolve with the same pace of the code.

If you really care about your documentation, you can also use branching to modify a wiki and create a pull request to validate those modification before they are public for everyone.

Gian Maria Ricci.

Leaving a VSTS Account

As a VSTS trainer, it is quite common for me to made students create VSTS Accounts, play with them and being enlisted in those account to help them in various stuff. It happens also that some customer gives me temporary access to the VSTS account, and in all those years, many of them forgot to remove me from the account.

This is annoying because each time Visual Studio or other tools try to understand VSTS accounts I have right to access, the list is really long. Luckily enough few months ago, the team added the ability to leave an account directly from your profile list.


Figure 1: Profile page where you can leave all the account you are not interested into.

So if you, like me, have access to VSTS accounts you do not care of, proceed to cleanup your access list leaving all accounts you are not interested into.

Gian Maria.

Public projects in VSTS

This is a long and awaited feature, not because VSTS should fight GitHub as Open Source repository standard, but because an organization is often composed by many private projects and some projects that are public and Open Source.

You can read about the new feature in this blog post, the feature is in preview, but will become available to every account in the future. Enjoy it.

Gian Maria.