My blog posts are like really terrible buses, you wait 8 weeks for one and now I’ve finally got a little time (3 hours on a train home from the midlands) so 2 or 3 are going to arrive at once.
A process template customisation I do regularly for customers is adding a Team field to scope Work Items to teams in TFS 2012 and TFS 2013. Microsoft have detailed the process here so it’s not a particularly controversial thing to do and I believe it provides a better experience when you have multiple teams working against a central backlog.
I blogged recently about how to use PowerShell to automate the process of adding a team field.
I performed the customisation for three companies in the last couple of months and bumped into a some issues with Team Web Access in particular. Even though adding a Team field is very much a valid thing to do, there can be a couple of wrinkles to iron out.
The first issue came as a bit of a shock. The background to the problem is this - a customer has been happily using TFS 2013 on a pathfinder project with a single team. Things have gone well and so they wish to roll out the tool to about 5 other teams.
We worked together to create a slightly customised process template which added some further hierarchy to the standard Visual Studio Scrum 2013 process template. Without thinking, I started work using a Visual Studio Scrum 2013.3 template and when I tried to upload it to the customer’s server we had some errors as Update 3 added all sorts of test related artefacts that weren’t available with the customer’s TFS 2013 RTM version.
That wasn’t the issue, however and I quickly made the changes to an RTM version of the VS Scrum template and uploaded it successfully. We then created a central project to house the company’s portfolio backlog (I must add that to my things to blog about!).
We were to resume working on the new project a few days later but before then I received a frantic email from the pathfinder team saying that whenever they tried to edit an existing Work Item using the Team Web Access client they received the following error:
Team Foundation Error The server operation failed, (Value cannot be null. Parameter name:key).
Team Foundation Error
The server operation failed, (Value cannot be null. Parameter name:key).
I quizzed the team on whether they had changed anything on the pathfinder project as templates are like cookie cutters, once you cut out the cookie, it doesn’t matter what you do to the cutter, it doesn’t effect the cookies you produced previously.
I went onsite and pulled down the processconfiguration.xml, categories.xml and the Work Item definitions for the pathfinder project. Nothing had changed!
Some experimentation confirmed that uploading a new process template configured to use a custom team field had broken Team Web Access for an existing project. Clearly that shouldn’t happen and although I we could have battled through and fixed it we took the decision to update the TFS 2013 RTM server (without knowing for sure that Update 2/3/4 had fixed the problem). We took the decision to go with Update 2 as we weren’t quite ready for the new test artefacts and I’d recently been badly burned by an issue with Update 3 massively inflating the collection database (another thing to add to my list of blog posts to write).
The upgrade to Update 2 only caused us a short period of downtime and it was something we were planning on doing soon anyway. The problem was resolved immediately so it was obviously a known bug which was addressed in the first update for TFS 2013 (there was no update 1 for TFS 2013).
A similar but not identical issue is discussed in the MSDN forum post here.
There are still 90 minutes left of my train journey so I may as well write up the next instalment.
Email Richard Erwin
© Copyright 2022 RippleRock