VSTS and TFS in the Real World

I've used VSTS and TFS for quite a while in pristine environments with clean installations.  As I mentioned a couple of days ago, Caleb Jenkins and I have been working with VSTS and TFS in an enterprise environment that was installed before we arrived and have been transitioning team with a mixed set of pre-existing tools.  I thought I'd share here some of the lessons learned and resources we have used to make things work.

First, we had a corrupted Active Directory entry that had been added to the TFS Valid Users group when a user decided that Domain\Everyone should be a reader to a team site.  That caused AD synchronization to break and the reporting data warehouse to stop updating.  It had been down for months when we arrived.  We used an MSDN support call to get MS to help hunt things down. Our hunt was complicated by the client requiring non-standard SQL Server ports for the original installation.  Apparently not all the diag tools work well when you have a non-standard port and an alias, due to miscellaneous copies of the port number in various config files.  I hope that's managed better in Orcas.  Once the AD account was removed, we had to delete the data warehouse in SSAS (not the relational database in the default instance) and force an update of the warehouse, using instructions that I think the support team found on MSDN for rebuilding the OLAP schema and cube.

Our next challenge was a permissions issue.  Soon after getting our warehouse rebuilt and reports working again, they froze up.  I turns out that the SSIS activity to update the cube fails and halts if it encounters a permissions problem where the service account has had permission removed from part of the SCM tree.  You would think it would log the exception and complete the migration so everyone else can see their data, but no.  It fails the entire migration and breaks reports for all teams using the server.  In our case, a project administrator had created special user groups with permissions to certain folders in their team project.  He naively removed the TFS Service account from the group and caused reporting data migration to fail for all teams.  Can you say brittle?  Again, let's hope this is fixed soon.  To solve the problem we had to look at the TFS server system application log for the error showing the change request causing a problem.  Then we queried for the group with that change request.  Then we perused the SCM tree of that group for permissions issues (using the properties dialog and the Advanced button to view permissions on an SCM folder).  Once we found the problem, we called the project team responsible and educated them.  I'm sure it will happen again and again until either the TFS Service account is implicitly made an administrator in TFS or the SSIS procedure is fixed to ignore permissions issues and move on with migration.

Once we felt like the TFS platform had been stabilized (we couldn't even install TFS SP1 with the original AD issue), we migrated our VSS, CruiseControl, NAnt project into TFS.  The VSS migration went well after running the analyze tool to clean up a copy of the repository.  Don't people known that VSS requires regular maintenance and archival?  Those repositories corrupt themselves if you neglect them, especially if they're over 4 GB.  Ours was 6 GB.  Then before biting off the challenge of re-writing our build scripts in Team Build, we used the CruiseControl plug-in for TFS and adjusted the NAnt scripts to get code with the TF command.  The trick is to manually login with the account running the CruiseControl service and setup a TFS Workspace with the right directory mappings.  Then give CruiseControl's config file the full path to the solution it should watch.  It worked quite nicely.  If you stop the CruiseControl Windows service, you can run it from a command line and see all the console output for testing and debugging the build.  That should give you insight into all the reasons that a build fails.

Finally, we rewrote our build scripts in Team build using NUnit (instead of converting hundreds of tests to MS Test).  We used the MSBuild Community Tasks Project on Tigris.org to execute the NUnit tests.  The examples don't show it and the syntax isn't obvious, but you can use the build task syntax of <NUnit assemblies="[project].nunit" /> to kick off a project file instead of a list of assemblies.  We use NUnit project files to maintain a list of assemblies for testing in the NUnit GUI.  Just store the project file as a solution item is VS2005 and associate it with nunit-gui.exe as the default app to open it, and it's ready at the double-click of the mouse.

Finally, with everything running smoothly we can get on to the job of enhancing the process and work item definitions using the new TFS Power Tools, which integrate nicely with VSTS and can be accessed from the Team menu.

Comments

[Jasper]

Hi Todd. I am playing a bit with TFS2008 and also believe in NUnit as an alternative to MS Test. Have you found a solution to get the NUnit results displayed in the TFS build reports? Best regards Jasper

[Todd Girvin]

Hey Jasper, no we never went that far with MSBuild. After numerous complications we reverted to the CruiseControl/NAnt configuration the team was already using. It's definitely not the level of integration that you get from MSBuild/TeamTest. We investigated migrating all the tests over to VSTS, but backed away from that, too. Now with VS2008, unit testing is in the Pro edition, so there's no real need for NUnit. The VS Test features are more advanced and integrated into the build the way you want.