Copy Work Items between VSTS accounts / TFS Instances

This is a very common question: how can I copy Work Items information from a VSTS account to another account, or between VSTS and TFS. There are many scenarios where such functionality would be useful, but sadly enough, there is no option out-of-the box in the base product.

If you do not have images or other complex data inside your WI and you do not care to maintain history, you can simply create a query that load all the WI you want to copy, open it in excel with TFS / VSTS integration (be sure to select all columns of interest), then copy and past into another Excel instance connected to the destination project, press push and you are done. This is only useful if you do not care losing images contained in description of your Work Item and if you do not care about history, because Excel is not capable of handling images.

Copy with Excel is a quick and dirty solution to copy simple WI in less than few minutes, without the need of any external tool.

If you need more fidelity you can rely on a couple of free tools. One of the greatest advantage of TFS / VSTS is that everything is exposed with API and everyone can write tool to interact with the service.

A possible choice can be the VSTS Sync Migration Tools, if you read the documentation, this is what the tool can do for you.

  • Supports all currently supported version of TFS
  • Supports Visual Studio Team Services (VSTS)
  • Migrates work items from one instance of TFS/VSTS to another
  • Bulk edits fields in place for both TFS and VSTS
  • Being able to migrate Test Plans an Suits from one Team Project to another
  • Being able to migrate Teams from one Team Project to another

It is a good set of feature and the tool is available with Chocolatey, so it is really simple to install. I’ve friend that used it and confirmed that it is really flexible and probably is the best option if you need high fidelity migration.

Another super useful function of this tool is the ability to map source fields to destination fields, an option that can allow you to copy Work Items between different Process templates. It comes with good documentation and it definitely a tool that worth a shot.

VSTS Sync Migration Tools is one of the most useful tool to move Work Items between Team Project. Mapping capabilities helps to change process template.

Another interesting option can be the VSTS Work Item Migrator tools, published on GitHub, it has many features, but is somewhat limited on the version supported, Source projects can be VSTS or TFS 2017 Update 2 or later and destination project can be only VSTS or TFS 2018 or later, so it is of limited usage if you have some older TFS instance. Nevertheless it migrates all Work Item Fields, attachments links git commit links and history, thus copied work items are really similar to source ones.

Gian Maria.

Be sure to use latest version of Nuget Restore Task in VSTS Build

If you have in VSTS some old build that uses Nuget restore task, it is time to check if you are using the new version, because if you still use the 0.x version you are missing some interesting features.

With VSTS build it is always a good habit to periodically check if some of the tasks have new version.

Here is as an example, how the version 0 is configured


Figure 1: Nuget restore task in version 0

In Figure 1 you see how you configure a standard nuget restore task, if you are using version 0 (2) it is time to upgrade, especially because the old version of the task is not so flexible about the version to use (3).

Before changing version, you need to know that the newer version of this task goes hands to hands with another new Task, the Nuget Tool Installer Task, that is designed to download and install a specific version of nuget that will be used by all subsequent task in the Phase.


Figure 2: Thanks to the NugetToolInstaller task you can ensure that a specific version of NuGet is present in the system and used by all subsequent tasks.

Nuget Tool installer also ensure that all nuget task will use the very same version.

After the Nuget Tool Installer you can simply configure Nuget Task in version 2, see Figure 3.


Figure 3: Nuget task version 2 in action

As you can see you do not need to specify any version, the version used will be the one installed by the Nuget Installer task, so you are always sure that the exact version of Nuget is installed and available for the build to be used.

As usual, if you have build that sits there for long time, take your time to check if some of the tasks are available in newer and more powerful version. If you wonder how you can immediately check if some of the tasks have newer version, simply check for a little flag near the description of the task, as shown in Figure 4.


Figure 4: A little flag icons warn you that you are using an old version of this task.

Gian Maria.

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 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.