Before we start: Don’t ever do this.

I am often asked if there is a way to see a “traceability matrix” in TFS. Different people define a “traceability matrix” in different ways. If you want to see how many tests there are for a set of requirements, then you can use SmartExcel4TFS. However, this doesn’t tell you what state the current tests are in – so you can’t see how many tests are passing / failing etc.

Unfortunately there is no TechEd Africa this year – Microsoft have opted to go for smaller, more focused sessions in multiple cities (or at least that’s what I gather). I think it’s a shame, since the TechEd Africa event was always fantastic – and who doesn’t like getting out the office for a couple of days?

Over the last couple of months I’ve done several implementations and upgrades of TFS 2013. Most organizations I work with are not developing boxed software – they’re developing websites or apps for business. The major difference is that boxed software often has more than one version of a product “in production” – some customers will be on version 1.0 while others will be on version 2.0 and so on. In this model, branches for each major version, with hot-fix branches where necessary – are a good way to keep these code bases separate while still being able to merge bug fixes across versions. However, I generally find that this is overkill for a “product” that only ever has one version in production at any one time – like internal applications or websites.

I was working at a customer that had set up a test TFS environment. When we set up their “real” TFS, they did a get-latest of their code and imported their code – easy enough. They did have about 100 active work items that they also wanted to migrate. Not being a big fan of TFS Integration Platform, I usually recommend using Excel to port work items en masse.

I’m well into my journey of discovering the capabilities of PowerShell DSC and Release Management’s DSC feature (See my previous posts: PowerShell DSC: Configuring a Remote Node to “Reboot If Needed”, Using PowerShell DSC in Release Management: The Hidden Manual and More DSC Release Management Goodness: Readying a Webserver for Deployment). I’ve managed to work out how to use Release Management to run DSC scripts on nodes. Now I am trying to construct a couple of scripts that I can use to deploy applications to servers – including, of course, configuring the servers – using DSC. (All scripts for this post are available for download here).

In my previous couple of posts (PowerShell DSC: Configuring a Remote Node to “RebootIfNeeded” and Using PowerShell DSC in Release Management: The Hidden Manual) I started to experiment with Release Management’s new PowerShell DSC capabilities. I’ve been getting some great help from Bishal Prasad, one of the developers on Release Management – without his help I’d never have gotten this far!

Just in case you missed it, Release Management Update 3 CTP now supports deploying using PowerShell DSC. I think this is a great feature and adds to the impressive toolset that Microsoft is putting out into the DevOps area. So I decided to take this feature for a spin!

I’ve started to experiment a bit with some PowerShell DSC – mostly because it’s now supported in Release Management (in Update 3 CTP at least).

We’ve been working on a rewrite of our Timetracking tool (formerly Notion Timesheet) and it’s going live today – Imaginet Timesheet! Timesheet lets you log time against TFS work items using a web interface. The web site can be installed on any IIS server (if you want to host it on-premises) or even onto Windows Azure Web Sites (WAWS) if you have a public-facing TFS or are using Visual Studio Online. Once you’ve installed it, just log in, select a date-range (week) and a query and start logging time.