Team System integration in a software organization - personal case study

I have been asked several times for my experience regarding installation of Team System inside an organization using (up to this point) an older version control system, so here are few tips:

1. Team system is a complex software to install, maintain and upgrade. Study the various pitfalls you may encounter and plan your installation strategy very carefully.
   You can find an updated installation guide and administator's guide in Microsoft's web site, and it's probably newer than the guides on your installation discs.
   Team system is mainly composed of the server's installation (I recommend a dedicated server), and an installation of the Team explorer on each developer machine. It uses SQL server as it's database server.
   Update: You should also read the "Operations Guidance for Team Foundation Server".


2. Decide and implement domain permissions for users (developers) and automated services.


3. If you also need to install SP1, be aware there are known issues with the upgrade.


4. Be aware to the fact there are several databases, so be sure to include all of them in your backup scheme. If you don't have a backup scheme - make one!


5. You also need to select a branching strategy that suits you for your source control.
   Update: Jeff Atwood wrote a great post explaining branching strategies.


6. You can also use VS2005 only for source control, and develop your application using VS2003 or Delphi (for example).


7. Choose how to use your infrastructure's assemblies repository. You can get them from the source control or store them locally on each computer, but then you don't guarantee all developers will use the latest version.
   Another option is using a shared folder to store them, but you make yourself more susceptible to network problems.
   One trick is using the window's subst command, mapping the shared folder to a drive, leaving you the ability to backup the repository locally and mapping it to the same drive if the network is down.


8. Create an automated build server. This takes some work, but will help you detect invalid code changes by developers. Choose the frequency to run the build at, from once a day to after every check in.


9. Don't fall for the NIH syndrome - there are many tools out there to make your life easier - use them.
   If you want to build non-native .Net code, consider getting a commercial tool (such as FinalBuilder for Delphi) and running it from your build code - it will be cheap compared to the developer-days you'll be saving.
   If you are using the bug tracking capabilities of Team System, be sure to remove the default event registration of the build service, otherwise your "fixed in ver" combo will contain hundreds of values. If you forgot, here is how you remove values from it.