OTSUG - Migrating to TFS 2010 - Lessons Learned

Editor's Notes

1. Read everything you can before you start. The more you can learn about the TFS 2010 installation procedures, the more likely you’re going to have a successful migration experience. Mention other guidance available on CodePlex other than the Visual Studio 2010 Upgrade Guide (e.g. branching guidance, requirements management, etc.).
2. Again, refer to the TFS Installation Guide for more information regarding hardware topology. Using new hardware/VMs allows you to perform a migration alongside your current TFS 2008 environment providing a simple backup plan if something were to fail.
3. Some facts about TPCs: You can’t branch across TPCs You can’t report across TPCs You can’t link to Work Items across TPCs Cover the fact that you cannot import TFS 2005/2008 Team Projects into an existing TPC once the TPC has been created.
4. This table depicts potential issues associated with the various migration types.
5. Pooled build servers provide the benefit of having a standardized build environment allowing you to easily scale out (e.g. by standing up a new virtual build server instance) as builds dictate. Pooled build servers also provide a simple approach to maintenance in that you can take build servers off-line (e.g. for patch updates, etc.) without affecting the build process. However, keeping multiple build servers in sync can be tedious at times and having to purchase licenses for commercial software may be prohibitive in some cases (tagging can alleviate some of these issues).
6. Existing work items are not updated during migration – i.e. they retain the “schema” of the original work item type definition they were created with. Mention the blog post above and that they provide a script that can be modified to suit most needs for updating existing work item types – assuming they haven’t been modified. If they have been modified, then you will have to manually “mash up” the custom work item types and the new TFS 2010 work item types and import them into each team project.
7. There are two types of Excel-based workbooks: Product Planning and Iteration Planning .
8. Some of these services may already by installed and running on other hardware – e.g. SharePoint/MOSS, SSRS, SSAS, etc. Mention differences between functionality & licensing for WSS & MOSS
9. Reiterate that some of these services may already exist in your organization and can be reused if desired. Mention that Build Servers still need to be setup and configured and will be covered shortly.
10. Mention that you can have only one Build Controller per TPC and vice-versa. A Build Controller can have many Build Agents but a Build Agent can answer to only one Build Controller. You can configure multiple Build Agents on a single machine – depending on hardware configuration. Discuss some of the challenges involved with tagged build agents – e.g. keeping them in sync, having the correct software, licensing, etc. Don’t configure the Build Controller and Agents until TFS is up and running. Otherwise, you’ll have to go back through and do it again.
11. Screen shot on next slide.
12. This is a screen shot of an upgrade – not a default installation.
13. Mention that you can have only one Build Controller per TPC and vice-versa. A Build Controller can have many Build Agents but a Build Agent can answer to only one Build Controller. You can configure multiple Build Agents on a single machine – depending on hardware configuration. Discuss some of the challenges involved with tagged build agents – e.g. keeping them in sync, having the correct software, licensing, etc.
14. It’s important to practice the upgrade process to ensure as little downtime as possible for the development teams. Make sure you have a fallback plan in case something goes awry during the migration – e.g. installing on new hardware allows you to keep TFS 2005/2008 readily available. If the upgrade fails, simply do nothing  If possible, create a “Playground” TPC as early on as possible. This will allow developers to kick the tires on TFS 2010 and possibly even practice the upgrades of their builds, check-in policies, etc. prior to the actual migration.
15. Provide guidance documentation for the various development teams so they setup their environments in a consistent manner. Some examples include guidance on permissions, folder structures, TFS machine topology, etc. If you have any custom build tasks, you will either need to compile against the TFS 2010 Object Model or ensure the TFS 2008 assemblies have been installed on the new build servers. If you start seeing merge candidates showing up that were successfully merged prior to the migration, you can use the following command line to remove the candidates from the list: tf merge /recursive /discard $/Project/DevBranch $/Project/MainBranch Mention that any hard-coded paths in the build scripts may need adjustment. Also mention there is a bit of a learning curve to the Workflow-based builds and that there will most likely be some custom build tasks being utilized in your builds that don’t have a direct corresponding Workflow Activity. Workflow-based builds will take time to implement throughout an organization.
16. Note that the “Edit build definition” permission seems to be unchecked by default. You will need to ensure that this is checked for anyone needed the ability to create new build definitions. Make sure the other permissions are reviewed as well (e.g. test-related permissions).
17. Note that while the TFS Administration Tool works with TFS 2010, it still relies on the TFS 2008 Object Model. Therefore, the Team Explorer 2008 Client (SP1) must be installed prior to installing this utility. Screen shot on next slide.
18. There are countless blogs dedicated to Visual Studio and Team Foundation Server – a lot of them directly from Microsoft and lots more from Microsoft MVPs. There is also a lot of on-line training available as well as video interviews, etc. For example, Microsoft’s Channel 9 (http://channel9.msdn.com).