Partager via

TFS Upgrade - Long Lead Preparations

  • Article

Planning an upgrade to Team Foundation Server 2015 is very similar to previous versions, so much of this post will be familiar from previous version upgrade guides if this isn't your first upgrade.  It's useful to plan your upgrade by organizing the work into two timeframes - long lead work (planning and tasks that can be done weeks or even months in advance) and short lead work (tasks that for one reason or another need to be performed the week or two prior to or during the upgrade process itself which is likely going to be done over the weekend).

A few things that are quite different for a TFS 2015 upgrade are:

  • Some schema changes can cause the upgrade to take longer
  • If you have a large database and choose to plan ahead, the TfsPreUpgrade tool can be run as a short lead task in advance to reduce the time the actual upgrade will take.

Upgrade planning meetings

If you are upgrading from a previous version of TFS, chances are there are probably a number of users across your company who now rely on TFS as a critical tool in their daily work. Meetings with the infrastructure team that monitors and maintains TFS, the lead developers who store and build their source code in TFS, the lead testers who manage their testing cycles and test cases in TFS and the project managers, business analysts and stakeholders that monitor project progress in TFS will be important. All these groups of users will need to be aware of the upgrade and can help you reduce risk in conducting the upgrade.

Here are some key things that each of these groups can provide that will assist in the upgrade of their TFS server well before the actual upgrade happens:

Developers:

  • Clean up old workspaces that are no longer used.

As developers come and go on a project, orphan workspaces inevitably occur. Many organizations upgrade their developer hardware or have new images put on their machines over time resulting in new machine names and thus new workspaces and orphaned workspaces and file check-outs.  Cleaning these up can speed up the upgrade process.

  • Identify build dependencies.

This used to be one of the trickier or work intensive elements of a TFS upgrade, as you had to ensure that all the builds worked after the upgrade. Now, this is a lot less important, as older build controllers and agents are now typically compatible with upgraded servers.

Infrastructure \ DBA team:

  • Previous databases have grown over time - the question is how much.

Long before the actual upgrade, a test backup and restore should be done if you are moving to new hardware. The backups tend to be larger than what the users think they will be, and if the databases are moving to a different location, the infrastructure or DBA folks should test it out. This is also a good time to test the movement of data so you know how long this step will take during the actual upgrade.

NOTE: Ensure that backups are comprehensive (config and all collections) and are verified.

  • Are the target servers up-to-date and running the minimum operating versions?

Check out the 2015 requirements document here.

All Users:

  • For all users of the new instance, are there new features that will require educational workshops to learn so users can get full benefit of the new version?

If this is a major version upgrade or maybe we've even stalled and this is a multi-version upgrade, there are probably new features that are big enough that we need to teach users how to use this new aspect of the tool and best practices. There are probably new features users aren't even aware of and we need to point them out and teach users how to leverage them to get all the potential goodness that the upgrade can bring. This is also a long lead task because changes in functionality or new features can impact business process for everyone that uses TFS.

Planning your new instance

If you are moving to new servers as part of your upgrade, it’s important to revisit and plan the topology for your new instance. If your organization has grown or if you've been risking downtime with a single front-end server this is a good time to consider load balancing the application tier. If your data tier is not clustered now is a good time to consider introducing redundancy to improve availability. If the current instance is on real metal, now is a good time to consider whether it makes sense to virtualize all or parts of your new instance or possibly moving it to the cloud in Azure. Refer to the TFS Planning and DR Avoidance Guide to plan your TFS infrastructure.

Team Project Collection Planning

First, managing the size of an individual collection can make upgrading faster and easier. As a collection grows past the 100GB or 200GB size range, backup and movement of the database can be a significant problem. If your organization is very large, now is a good time to consider breaking up the set of Team Projects into non-related collections. For more information please read the Split a Team Project Collection MSDN article. Going to multiple collections in a large enterprise allows for scaling the database across multiple SQL server instances. This could be important if your SQL Server performance is starting to show signs of stress.

Related Posts

Authored by Mike Abrahamson
clip_image002_thumb[1] Mike is a Principle Consultant, based in Minnesota focusing on Application Lifecycle Management. Mike has Enterprise level experience leading ALM projects that help customers use Team Foundation Server to enable their business and ALM processes. Mike focuses on defining and delivering software solutions with an emphasis on process maturity and quality throughout the software development lifecycle.