TFS Upgrade - New Elements of TFS 2015 that influence an upgrade
Today we'll begin a series of informational blog posts targeting the latest release of Team Foundation Server 2015. In these posts we'll cover many of the major changes in deploying Team Foundation Server that are new to Team Foundation Server in 2015. Some new aspects may be expected and some may come as a surprise, but either way you'll have the information, tools and advice that will hopefully make your deployment easier, faster or just plain better experience than going it alone.
So first, how do you get from here to there? Many times users that have lingered on older version have the biggest challenges and that will be true here as well at least in terms of the time it takes to upgrade to TFS 2015. There are direct upgrade paths from TFS 2010 SP1 and up.
If you're all up to date and already running TFS 2013 the good news is that generally, system requirements have not changed from TFS 2013. TFS 2015 will support the same SQL versions as well as support the same operating systems.
One of the first things to note is the TFS 2015 upgrade process is going to be quite slow due to schema changes similar to the upgrade from TFS 2010 to TFS 2012. The long upgrade process is due to a new column added to most tables in support of the new Team Project rename feature in TFS 2015. Yes, in some cases in order to get the good of new features we have to deal with the bad of transformation.
Let's learn more about the database changes and a tool developed by the product group that we can run to proactively do work on the database to be upgraded in order to reduce the time it takes to upgrade the given instance to TFS 2015.
The tool is called TfsPreUpgrade tool. Very catchy name eh? What it does is setup temporary tables and triggers that not only starts the upgrade on your running instance of TFS so the upgrade doesn't take so long, but it installs triggers that will keep it up to date while it's being used. There are a few catches of course. First you'll need to be on TFS 2013 QU4 or QU5. It would have been a feat in deed to create a tool that was able to do this job on all legacy versions of TFS. The second catch is that having these triggers running on your instance will take some resources and you'll want to minimize the time between running this tool and the final upgrade. So in our upgrade check-list, running this tool will be closer to a short-lead task than a long-lead task.
So what happens if you run the tool and stop it half way through or your upgrade timeline changes? No problem, the tool can be both cancelled and restarted. It also has a revert option that will delete the new tables and removes triggers. But keep in mind that this will likely be used on your production instance, so let's be smart and deliberate when we use the tool.
The largest impact of the Team Project rename feature will be on the Version Control tables (tbl_Version, tbl_LocalVersion, tbl_LabelEntry, tbl_MergeHistory, tbl_ExtantItem) but there's also work it needs to do on build (tbl_Build, tbl_BuildInformation, tbl_BuildInformation2, tbl_BuildQueue) framework (tbl_File, tbl_PropertyValue) and WIT (WorkItemLongTexts, WorkItemFiles) tables.
How slow is slow? A very rough estimate of total time is 24 hours per billion rows across these tables. Yes, that is a VERY large database but they do exist. To give you an idea, the Microsoft Developer Division upgrade would have taken 7-10 full days, if not for this tool that did some of the work up front.
The TfsPreUpgrade now includes an Estimate command which can be run to give an estimate of the time required for pre-upgrade, which can also give a rough sense of the magnitude of time required for offline upgrade. The two times will be different, but not by an order of magnitude or anything like that. It also spits out these estimates automatically when you execute the Run command.
Is there any good news? Yes, in the TFS 2015 upgrade deployment we have Severe Warnings. Wait, that's good news? Yes, previously, our readiness checks would produce warnings (which were easy to ignore) and errors (which are blocking). In the TFS 2015 upgrade process we wanted the ability to force people to think about warnings, but allow them to proceed anyways. Here's an example:
There are a few areas where these warnings can occur:
- Size of tables handled by TfsPreUpgrade exceeds a threshold.
- Language of deployment changed.
- Attach: domains cannot be resolved.
Some new build elements have also been added in the upgrade, so there's an additional page for the application tier build agent included in all wizards, including Upgrade.
Check out the Use TfsPreUpgrade to reduce downtime for more info.
Well that's it for now. In our next post, we'll drill into some details of the TfsPreUpgrade tool and see how it can go a long way to making sure that the upgrade process can be completed over a weekend, no matter how big the database is.
Related Posts
A special thank you to everyone who laid the foundation on previous and current TFS Upgrade guides: Aaron Hallberg, Ajay Bhosle, Allen Clark, Andre Scripa, Anisha Pindoria, Bijan Javidi, Caroline Williams, Christian Nielsen, Ed Holloway, Ewald Hofman, Fabio, Stawinski, Francisco Fagas, Gordon Beeming, Hosam Kamel, Jeff Bramwell, Jens Suessmeyer, Jim Szubryt, Martin Hinshelwood, Mattias Sköld, Michael Fourie, Mike Abrahamson, Osmar Landin, Patricia Wagner, Petr Moravek, Pierre Donyegro, Pieter Gheysens, Pramod Vasanth, Stefan Mieth, Stephen Olner, Tony Feissle, Thomas Isler, Vlatko Ivanovski, William H. Salazar, Willy-Peter Schaub.
Authored by Mike Abrahamson
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.
Comments
Anonymous
December 08, 2015
We recently upgraded our TFS from TFS 2013 Update 3 to TFS 2015 update 1. In the web portal we see all of the dashboard widgets. The SharepPoint Portal and SSRS reports are under the "other links" with Manage Areas and Iterations. SSRS reports and view project portal are not showing as real links. We ended up adding the Markup dashboard to expose the links for these. As we do not want to have dead links under "other links", is there a means to remove them as to not confuse our user base? Thanks.Anonymous
December 08, 2015
We recently upgraded our TFS from TFS 2013 Update 3 to TFS 2015 update 1. In the web portal we see all of the dashboard widgets. The SharepPoint Portal and SSRS reports are under the "other links" with Manage Areas and Iterations. SSRS reports and view project portal are not showing as real links. We ended up adding the Markup dashboard to expose the links for these. As we do not want to have dead links under "other links", is there a means to remove them as to not confuse our user base? Thanks.Anonymous
December 14, 2015
Sorry for the slow reply here Greg, I've been asking around to try and see if anyone has any ideas. I’m not sure what you mean by “real” vs “dead” links on the Other Links widget, however all widgets can be removed now. If you don’t want those links confusing your user base you could just remove the Other Links widget from the dashboard yes?