Freigeben über

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

  • Artikel

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.

Comments

  • Anonymous
    October 09, 2006
    Brian Harry on Promised SP1 docs and Last Word on TFS Expirations (I Hope). YuTong on How to Enable...

  • Anonymous
    May 30, 2007
    Hi Andrew,Great if you could throw some light on the following.How did you change the version control integration used in TFS? We also have a custom build set up and I want to integrate the build numbers from this system.The MSSCCI Provider for 2003 asked for credentials and failed to validate. We dont have any forest issues as you mentioned. Thanks!Sudheer

  • Anonymous
    May 30, 2007
    Hi Sudheer,Some thoughts/answers:From a build perspective, we had to be able to label the latest source (with the build id), retrieve it and then build it. All of this was done by coding against the TFS client object model. The basics are outlined in http://msdn.microsoft.com/library/en-us/Extensibility_Guided_Tour/The%20Version%20Control%20Object%20Model.aspI haven't seen a credential validation issue with the provider (other than the usual suspects). If you're able to hit TFS with Team Explorer, you should be able to use the MSSCCI provider from VS2003. Our forrest issue was solved by simply setting the Login ID (in domainusername format) on Tools->Options->Source Control->SCC Provder. Andrew