Archives for October 2015

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:

ForwardCompatAction

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

vsoAgentPSTask

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.