The Road to TFS - Experience from the Field (Part 2)

  • Article

This is a follow-up to my last post where I'll talk about the highlights and lowlights of our TFS deployment project. 

So how were the requirements met?

  • Yes, we used VSSConverter. It turns out that that it's quite a resilient tool. We managed to import over 162,000 files with their respective histories, even with a few server issues (more on this later). The whole process was completed in under 12 hours.
  • VS2003 integration was delivered via the MSSCCI Provider for TFS.
  • We actually continued using CruiseControl and NAnt for the .NET 1.1 build server. We did investigate moving to Team Build, but we decided our efforts could be better spent elsewhere. This did however require us to rewrite the version control integration code used by the build solution.
  • In order to handle the security requirements, we created a customised Process Template for the VSS database in question and generated both TFS groups and TFS areas for each resource being secured. By default, developers were granted read-only access to Version Control and only picked up read/write access to a resource through membership of the resource-specific group. We did some creative stuff with XSLTs to generate the Process Template from a VSS directory structure. Group membership was seeded from another database and is managed on an on-going basis via a simple website (that was part of the original central build solution).

And what didn't work as expected? Well, there were a few bumps along the way...

  • Repeated trial migrations (of the same VSS database) got slower and slower. With help from PSS, it appears that reapplying the same label over and over causes inefficiencies. We had a lot of labels (added by the central build solution), so this hurt us bad! Fortunately we were able to torch our TFS database and move on. The moral of the story is get yourself a development TFS server and be prepared to restore it to a clean state on a regular basis.
  • We encountered out of memory issues on the Application Tier. This seems to have been related to the first issue, but we still got a couple on a clean TFS database. In the end, VSSConverter coped with this and finished its work successfully.
  • The MSSCCI Provider prompted for a username and password at first use, which was a potential show-stopper because we almost exclusively use SmartCards for workstation access. This was traced to our TFS boxes being in a different forest to the clients and could be avoided through some client-side config.

So how did it pan out? You'll need to read my next post to find out.