Recently I took the opportunity, safely between product releases, to upgrade our TFS 2008 server to TFS 2010. I performed a Migration Upgrade to new virtual servers. I have a server for each tier, Application, SQL Database, Analysis Server, Reporting Server and Build Server. Overall the upgrade was very smooth and error free. Very impressive work done by Microsoft to get this complex operation simplified. I had absolutely no issues with the version control or work items, so downtime for my team was very minimal once they installed the forward compatibility update. I did however have some issues, which I will outline and the solutions I found.

Backing up our existing TFS databases, transferring them across our (slow) network and restoring them on the new SQL Server, was the longest task. The actual upgrade by the TFS 2010 administration of the TFS 2008 database (about 25GB) took around an hour. Not bad.

The data warehouse did not update right away. I had to manually trigger a rebuild. Using the cube afterwards we found it was not fully populated. This was very odd and gave the first use experience of the new cube a very bad impressive. Over the week however, I was monitoring the warehouse views and database size and saw this steadily increase until all the data was in there. We have our own BI Reporting tool, so all our existing reports were completely broken due to the cube schema changes. The jury is still out whether the cube is easier to use or not, but we are now powering away rebuilding all our reports.

Most of the pain was getting the new build server up and running. This is partly due just to getting our prerequisites in order, but there were a few issues from Team Build 2010 itself, since we were not upgrading to Visual Studio 2010 just yet (we will soon).

Firstly, MSBuild 4 failed to detect dependencies. This caused the projects in the solutions to build out of order, and subsequently fail. The solution is to update the dependencies manually in the solution file and the fix is found here.

Secondly, it failed to find the Bootstrapper SDK path. A reinstall of the Windows SDK may have helped this, but the easy solution is to just edit the registry and add the path. Solution found here and here.

Thirdly, and most painfully, and still not resolved is that the Test Results are not published and the error message is TF270015: ‘MSTest.exe’ returned an unexpected exit code. Expected ‘0’; actual ‘1’. This means that they are not available from the build details, the drop folder or the cube. I can only see the test results by looking through the text MSBuild log file. This issue has been resolved but the fix is not yet available. I assume it will only be available after we have moved to VS 2010 anyway which does do much better management of Unit Tests by removing the need for the horrible vsmdi.

Lastly, we still get numerous TFS237086: The work item cannot be saved because at least one field contains a value that is not allowed. I do not know why we get this message sometimes especially since the work item number quoted has been updated and associated with the build and there is no invalid state of it. One theory is that multiple builds are updating the same work items and the build does not refresh the work item just before it updates it.

The Reports node in Team Explorer had a red cross on it and I was eager to see the new reports. I found that the new instance of Reporting Services did not have the correct permissions for the users. Fixing that and the Team Explorer reports node came good and the old TFS 2008 reports all worked against the new data warehouse and cube. Nice. The new reports however, were not there. Importing them from the exported CMMI Process Template did not map them to the data sources correctly. Manually fixing that got them working, but I imported them to the wrong folder structure, so the links did not work. Later I found this page which outlines a process to import the new reports. I am most interested in the Excel reports, but I have not connected to SharePoint yet, since I will wait till we upgrade it to SharePoint 2010, so I was quite disappointed I could not get them without SharePoint. We use our own reporting tool anyway, so this was more for interest and replicating the Reporting services reports in our BI tool from the Cube was very easy.

Once the builds were working I set off to enable the Test Case Management which is a big reason for us to upgrade to get started with right away. Following the instructions here was easy although there were errors, but the user comments are helpful getting around them. I had already quite heavily customized our work item layout so I did not have to follow many of those modifications. It was a very simple task with just these steps:

1. Download the Process Template
2. Import Link Types (Shared Steps and Tested By)
3. Import the Work Item Types (Test Case and Shared Steps)
4. Import Categories
5. Modifying the Bug template, just to add a couple of fields. I did not modify my layouts.
6. Specify the Bug Type to and bugfieldmappings for Test Manager
7. Grant permissions

I did this for two projects and the second time was very quick. There were however issues at step 3, 5 and 6. Firstly, step 3. The downloaded work item template has the new Names for existing Fields. This caused the error TF212018: Work item tracking schema validation error: TF26177: The field System.IterationId cannot be renamed from ‘IterationID’ to ‘Iteration ID’. This involved just editing the work item type xml. For me, it was:

TestCase: Area ID –> AreaID
SharedSteps: Area ID –> AreaID; Iteration ID –> IterationID

Second, step 6 which caused me to go back to step 5 later. This was painful! Bug Field Mappings. Contrary to the article and name of Bug MAPPINGS, you cannot specify another field you want the Test Runner to populate. I have tried to get it to use the existing Microsoft.VSTS.CMMI.StepsToReproduce field with no avail. MVP Ed Blankenship has confirmed this, that the values are hard coded! So thirdly, was to go back to step 5. To resolve it I had to:

1. Add the new ReproSteps field.
2. Set it to copy StepsToReproduce.
3. Update all Bugs work items in the project by adding a comment in the history. (Use Excel, the new bulk edit in the web access is slow!)
4. Edit the form to display ReproSteps where it was StepsToReproduce
5. Remove the Required on StepsToReproduce and add it to ReproSteps

Now though, the Test Runner populates our Bug templates nicely, and performing these on the second project was quite quick. However, the upgrade could have been much smoother if the mappings worked. It felt like Microsoft had disregarded existing installs in this area. Next steps are now powering ahead with the new test case management, which seems nice, but the Test Management interface is certainly version 1 to put it nicely. Upgrading our projects to Visual Studio 2010 to get more benefits from TFS 2010 with the client designed for it. And plan the next iteration with the hierarchical work items.