We had a great session yesterday at the Israeli ALM User Group. The session was about how to prepare to a TFS 2012 upgrade. We were quite surprised with the success of the session since we weren't so sure there will be much interest in this subject. Well, we were wrong. There was much participation from the audience. People were asking questions and contributing from their own experience. As you can see from the first slide we were quite sure that this is a boring session…
We would like to summarize the main points we have raised during this session in the post to help you prepare for your upgrade as well. Please notice that this is not a user guide for a TFS 2012 upgrade but a post with some points that we think can be useful to know of before you start your upgrade. You should follow the official MSDN documents published by Microsoft.
1) Why to upgrade?
If you haven’t notice what’s happening with Visual Studio 2012 and with TFS in particular you need to wake up! Read some posts from Microsoft to find out about the newest additions to the product.
2) Why do we need to prepare?
Upgrading TFS was always an easy process. We do think that since 2005 until 2012 some things changed. We are using more features, the product continuously changed and the most important thing is that our data grows. TFS is a mission critical system. We want our upgrade to pass smoothly. The good news is that it is still an easy process but… we need a plan.
3) Do a test run
We recommend to do a test run of the upgrade before doing it on your production environment. This is a good way to check your disaster recovery procedure for TFS. If you don’t have one then this is a good time to have. There are some ways to do it and it depends on your environment and your infrastructure. Some use virtualization to clone their TFS environment and to run a test upgrade on it. Choose what you think is best for you. We recommend to get familiar with Microsoft documents about how to move your TFS from one hardware configuration to another.
Move Team Foundation Server from One Hardware Configuration to Another – this is the guide describing a full move from one hardware configuration to another. After you done this you can keep the new hardware configuration and use it for future restores. When doing future restores you can use this guide: Restore Data to a Different Server or Instance.
4) Communicate the upgrade
Get your customers involvement in the upgrade process (Developers, QA Testers, Project Managers…). You would like them to tests their clients and tools and get their feedback ASAP in case of issues.
5) Know your environment
It is important that you map your environment so you will list the software to upgrade and the order of doing it. Here’s a mapping we've done for an environment we have upgraded.
6) Know your TFS service accounts
This is a critical part. You need the service accounts you have used during TFS installation for the upgrade. Don’t start the upgrade without having them. During the session we were asked a question about it by someone that probably used the NETWORK SERVICE account during the upgrade and was facing issues with TFS. You need 2 accounts (it can be one if you decided on it). The account for the Application-Tier and account for the Reports.
7) Update relevant software
Upgrade your Windows and SQL Server to meet the TFS prerequisites.
i. Windows Server 2008 R2 SP1
ii. All other updates
b. SQL Server
i. 2008 R2 or 2012
1. We recommend to wait with the upgrade to SQL 2012 since TFS 2010 does not support working with SQL 2012 if you will need to rollback you upgrade.
ii. If you are running 2008 R2 Enterprise you need Cumulative Update Package
c. Team Foundation Server
i. 2008 SP1
DO THIS IN A SEPARATE PROCESS BEFORE THE UPGRADE – Windows Server 2008 R2 SP1 update can take 2 hours. You don’t want to wait for it when you are upgrading TFS. Schedule another update before the upgrade.
8) 3rdParty tools
Check to see if you need to upgrade to a new version of a 3rdParty tool your team is using. Be on the safe side and check if you are eligible to an upgrade of you need to purchase the new version.
9) Internal tools
Compile your internal tools and take the needed actions to be ready:
a. Work item custom controls - compile with Visual Studio 2012.
b. Internal tools – compile with Visual Studio 2012.
c. Visual Studio plugins - Install Visual Studio 2012 SDK and compile.
d. TFS soap notifications – compile with Visual Studio 2012. They should work without compiling but be on the safe side if you used API that might changed.
e. Build XAML and custom actions – compile with Visual Studio 2012 and clean XAML files.
i. Tool to update XAML files – Cleaning up Workflow XAML files (AKA removing versioned namespaces)
All TFS referenced assemblies are placed at Common7\IDE\Referenced Assemblies\v.20\ and not at 4.0
10) Schedule a downtime
A small project collection upgrade took few minutes. A 3 years old project collection upgrade took few hours.
11) Stop TFS services and perform a backup before the upgrade starts
You don’t want your users to use the system while doing the final backup before the upgrade. Remember to stop TFS services to disable connecting to the system.
As for the back, if you are upgrading from 2010 you can use the 2010 back up power tool. For early versions follow the backup guide: Back Up Team Foundation Server.
12) Upgrade TFS
Follow the instructions using the official guide: TFS Upgrade Requirements. It will take you through your relevant upgrade path.
13) Uninstalling the previous version
You need to uninstall TFS previous version before installing a new one. It’s OK to do so and it does not affect the databases. After installing the new version you will run the TFS configuration wizard and select your existing database.
14) Run the configuration wizard
You need to uninstall previous version, install TFS 2012 and run configuration wizard for all relevant server (TFS, Build agents, Proxy…).
15) Review the results
It is important to review the results of the upgrade wizard. In this case the upgrade was successful but TFS could not associate the existing build agents. That’s ok. We had to upgrade them and associate them manually. We had a strange behavior while associating the build agents. It seems that we succeeded but after few seconds the coordinator and build agents were disconnected. Looking at the logs we found out it was a memory problem on the single server deployment we had so we have configured SQL Server to use less memory by default and problem was solved.
16) Run some tests
Run some tests to see that your system is working as it should. This is the time to ask your customers involvement.
a. Check clients and tools
b. Check in code
c. Run a test build
d. Check data/reports
That’s it. You should know that some of the following symptoms might occur during the following days after the upgrade:
· A build fails after check-in. Developer: “It’s because of the upgrade”.
· 3 years old laptop works slowly. Project Manager: “It’s because of the upgrade”.
· An error while posting a status to Facebook. QA Tester: “It’s because of the upgrade”.
You might be facing some issues after the upgrade. The most important thing to do is relax and read the logs. J
Post a Comment