Calling scripts in RM2015 vNext style

I recently improved all of my powershell scripts for RM2015 vNext deployments by including a param() clause at the start of each script. Only to discover that when using PS/DSC actions in RM2015 (and 2013 for that matter) you cannot pass parameters! Quite frustrating as the main reason i did this improvement was because of Microsoft’s message at the end of their Release Management vNext Plans blog post

To maximize the chances of carrying your investments forward, we recommend that you write PS scripts to drive your deployments with the current versions of RM server

and the default/recommended way to work with powershell scripts using the PowerShell on Target Machines VSO agent task is to pass parameters. Sure, the VSO agent task has the advanced option “Sessions Variables” for backward compatability but I would really prefer to make my RM2015 solution forward compatible instead.

So how do I make my RM2015 scripts and release templates forward compatible? Turns out it is not that difficult to achieve. You’ll need a generic wrapper script and three variables in RM. Your wrapper script should look like this:

Invoke-Expression "$PSScriptRoot\$PowerShellScript $ScriptArguments"

Make sure your wrapper script is included in your build drop together with your other deployment scripts. Then add three global variables in RM2015.

  1. PSScriptPath – set the value to the “drop releative” path of your wrapper script. (If this path differ between components make this a component variable instead)
  2. PowerShellScript – do not set a value at the global level, we just want the variable to show up in the dropdown list for Custom configuration in our PS/DSC action.
  3. ScriptArguments – do no set a value at the global level, same reason.

And now, your PS/DSC actions can look like this:


which corresponds nicely with how it is done in the VSO agent task:


We are now forward compatible!

TFS and VSO guidance – Area path

Team and organizations that are new to TFS almost always struggle with how to structure their hierarchy for the Area Path field.  The documentation might seem straight forward: “Area paths allow you to group work items by team, product, or feature area”. However, most teams quickly discover that this is easier said than done.

First of all, do not use area path to track teams unless you have to (currently no other way to do it in VSO). I’ve explained why in a previous post.

Second, start small with broad areas and add more detail (child nodes) as needed. I’ve seen too many teams getting stuck on implementing a “complete” area path hierarchy thinking the field wont be useful unless they have it all in place. Most of the time that is a real waste of time, usually resulting in a way too detailed hierarchy where many nodes are never used. Use an agile approach instead and add detail where needed, when needed.

Third, keep a user centric view. A very common scenario is that the area path hierarchy is defined by the development team usually resulting in something relating to the software architecture. Unfortunately this is rarely useful to non-developers, e.g. Product owner, stakeholders, end users. Product features or workflows are usually more useful as it makes more sense to the non-developers (typically the ones creating new requirements and bugs) and for reporting purposes. One of the most interesting solutions I’ve seen, and personally feel makes a lot of sense, is to map the area path hierarchy to the user manual’s table of content.


This is the second post in a series where I will try to give you some solid guidance on TFS/VSO or point you towards existing solutions and recommendations.

Visual Studio 2015 ALM Virtual Machine

There is finally a new Brian Keller Virtual Machine (BK VM) available, only it is no longer Brian Keller who is in charge.

The new home of the VM is the Visual Studio ALM VM blog. For anyone who wants to learn more about Team Foundation Server (TFS) and Visual Studio ALM platform this is almost a mandatory download.

TFS and VSO guidance – Teams

I often get questions along the lines of “How do we do this in TFS?” It can be anything from setting up teams to choosing the best process template or how to structure a useful area path tree. My answer is always “Well, it depends…” because that is the truth. It really does depend on quite a lot of things. Fortunately, most of the time, you can change how you do things as you gather more and more experience from working with TFS in your organization. On the other hand, if you start out wrong it might require quite a lot of work to rectify that mistake. This realisation quickly turns the original question into “Ok, so how are we supposed to do this in TFS? Are there any recommendations or best practices? What does Microsoft say?”

Well, if you take a quick look at MSDN Library you will quickly realize that Microsoft actually has quite a lot to say. But over the years they have become less and less prescriptive. Which is good. Unless you are looking for some solid pointers… As far as recommendations and best practices goes these golden nuggets of information can sometimes be difficult to find.

So, this is the first post in a series where I will try to give you some solid guidance on TFS/VSO or point you towards existing solutions and recommendations. These posts will be based on my experience from working with TFS over the last 10 years.

Setting up Teams

What you need to know here is that the default way of setting up Teams in a Team Project is flawed. It works, but it is flawed and it will often cause grief down the road. Why? Because it uses the Area Path field to define your teams. This is not what the field was originally intended for. The Area Path field is intended to categorize work into product areas. The team is not a product area. Having multiple purposes for one field is bad design and this will quickly become apparent when you want two teams to work on the same product as you suddenly find yourself maintaining two identical area path structures in TFS, one for each team.

A much much better way to set up teams in TFS is to add a separate Team field, which is actually fully supported by Microsoft and opens up a hidden Team settings interface in WebAccess. It will require some customization of your TFS but it is definitely worth the effort.

Team field settings page

Unfortunately, for those of you who are using VSO it is currently not possible to do the necessary customizations in VSO. You’re stuck with the default. This might change in the near future though as VSO process customization is coming.

VSO in Europe

Great news for those of you who want to use VSO (Visual Studio Online) but did not like the idea of having all your data in the US.

VSO is now hosted in Europe as well! To be more precise it is hosted in the Netherlands.

This should make VSO a viable option for many organizations and government agencies in Europe. For those of us in Europe not restricted by law or company policy it is still great news as it offers a VSO option with lower latency.

So, a short summary:

  • For now you have to create a new VSO account for this
  • It will be possible to move your account from “South Central US” to “Western Europe”, but not yet. You have to wait a few months for that.
  • The entire account has to be hosted in one place. You can not have some of your Team Projects hosted in the US and some in Europe unless you create them on different VSO accounts.

You can read more about the details on Brian Harry’s blog.

ALM Rangers want your feedback and ideas

I’ve always been a fan of the ALM Rangers’ solutions but until I joined them I was not really aware of how I could influence their work. So I thought I’d share that info here in the hope that some of you will vote for ideas and give some valueable feedback.

So, what can you do?

  1. Go to the Visual Studio UserVoice site and post/vote for ideas. Use the “Rangers project” category to see ALM Rangers specific items.
  2. Keep an eye on Willy-Peter Shaub’s blog for anything Rangers related and public request for feedback, like this post.

That’s it. Quite simple really. Wish I’d know about it years ago.

If you havent heard about the ALM Rangers before you can read about us and what we do here.


Starting with TFS 2012 we are now faced with the options of using either Team Foundation Server or Team Foundation Service as our ALM platform of choice. The big question is which one to choose. One is installed locally while the other is hosted in the cloud. This is an important difference but not the only one. I’ll list the most important points to consider here.

The cloud

If for some reason you are not allowed to handle your work items or source code in the cloud then Team Foundation Service is out of the question as it is based on Microsoft’s Windows Azure platform.

Installation and administration

Installing Team Foundation Server has become much easier than it was back in 2005 but can still be a bit tricky. Using Team Foundation Service is basically a matter of supplying a name for your instance. If you dont want the hassle of server installation and administration then you should consider Team Foundation Service.


Process templates are not customizable in Team Foundation Service. If you think you will have to make adjustments to the process template (like adding new fields to work items) then you probably want to go with Team Foundation Server instead. Unless you are ready to wait, because this will change in the future.

Document management

If you want solid document management features then Team Foundation Server is the way to go as it includes Sharepoint. Team Foundation Service currently has no document management features. This will change in the future with Office 365 integration (see Brian Harry’s first response in the comments).


One of the many nice features of Team Foundation Server is all the reports you get out of the box. Apart from sprint burndown charts you get no reports at all in Team Foundation Service. This might be perfectly fine for some or a complete deal breaker for others. This will probably change in the future but I’ve been unable to find anything to support this claim. Windows Azure SQL Reporting is available though so hopefully only a matter of time before it is integrated into the Team Foundation Service offering.

Price tag

There is actually a pricing preview for Visual Studio 2012 (and Team Foundation Server)  but very limited information about Team Foundation Service pricing.


There are other differences but this should cover the most important aspects. If you want to dig deeper, have a look at the Team Founation Service whitepaper.

New scrum guide

Ken Schwaber and Jeff Sutherland, the co-founders of Scrum, have been working together and with the Scrum community on updating the official Scrum Body of Knowledge, the Scrum Guide. The core principles of Scrum remain, but misunderstandings have been clarified and techniques have been removed. The “Definitive Guide to Scrum,” focuses on the framework, rules, and ceremonies of Scrum. Emphasis is placed on the roles of the Scrum Team and understanding of their responsibilities, as opposed to the strategies and techniques involved in fulfilling those roles and responsibilities.

The new scrum guide was announced on July 15 but the reasoning behind the changes are not always clear to everyone. To remedy this is releasing a series of Scrum Guide Explanations. These explanations are really good, not only do they explain the specific change in question but reading the explanations will also give you a deeper understanding of the core principles of scrum.

If you are using scrum today or plan to use it in the future I strongly suggest you head over to and check out both the new Scrum Guide as well as the Scrum Guide Explanations.

Test steps and results in TFS 2010

All SSRS reports you get out of the box with TFS 2010 are trend reports and they don’t show any details. I was recently asked to build a custom report listing all test cases in a test plan and for each test case every step should be listed with action, expected result ant test outcome. Basically the same kind of info you can get for a single test case when you view the test results in Microsoft Test Manager 2010. This turned out to be quite a bit trickier than expected but after getting some much needed info from a developer at Microsoft (thank you Sriram) I was able to get it all together.

Getting test steps and results from Tfs_DefaultCollection

Test steps are stored as XML and are found in table WorkItemLongTexts. You can use this query to get them.

declare @fldIdSteps int = (Select top 1 fldid from Fields where ReferenceName = ‘Microsoft.VSTS.TCM.Steps’)      select * from WorkItemLongTexts where FldID = @fldIdSteps

Test results for each step are found in table tbl_TestActionResult. You can use this query to get them.

select * from tbl_TestActionResult

Now, you’ll notice there are a couple of issues popping up. You’ll need to join a XML result with a table result, there might be several revisions of the test steps and there are probably many results saved for each and every test case. But most of all, there is no obvious way to link steps to results. Every test step has an ID but tbl_TestActionResult does not contain a “test step ID” column.

ActionPath explained

This is where the column ActionPath in tbl_TestActionResult comes in. This column will typically contain an empty string, 8 chars string or 16 chars string. For a specific test result in a test run there will be one line with the empty string (this line is the over all test result) and then one line for each step, containing 8 or 16 chars. These ActionPath chars are hierarchical hexadecimal representations of test step ids. The first 8 chars is the step id and the next 8 chars (if they exist) is a shared step id.

And now you have the knowledge needed to pair up test results with corresponding test steps!

Some issues to consider…

There are a few more issues you’ll have to tackle as well.

  • Step ID != Sequence number. The test step id is not the same as the numbers you see when viewing a test case in a GUI. The numbers you see in the GUI are generated in the GUI to clarify the step sequence. The step id is never shown and the sequence number is not stored in the database. You’ll have to rely on the order of the <step> elements in the XML to figure out the step sequence.
  • Revisions and result. There can be several revisions of the test steps stored in table WorkItemLongTexts and there can be several test results stored for each revision. You’ll have to compare timestamps for revisions and results when joining them to avoid errors.
  • Performance. The Database Tfs_DefaultCollection is the production database and you should always take performance hits into consideration before deploying reports that read directly from your production database.

More details

When I first tried to figure out how this all worked I put a question up at the MSDN forums. For SQL and code samples you can go to my post on MSDN and get some more details.