Fragestellung:
Sie fragen sich vielleicht ob Sie ein Upgrade von Ihrem TFS 2005/2008-System auf den TFS 2010 problemlos durchführen und "überleben" können?
Antwort:
Ja, aber…
Die gute Nachricht: es gibt einen einfachen Upgradeassistent der die Datenbanken in das neue Format konvertiert und somit geht auch nichts verloren.
Sie haben dabei die Wahl zwischen zwei Wegen:
- Weg 1: "In-Place Upgrade" auf der gleichen Maschine
Sie deinstallieren den heutigen TFS, im TFS 2010-Konfigurationsassistent die Option "Upgrade" wählen.
oder - Weg 2: Upgrade auf eine saubere Maschine
Hierbei wird parallel zu Ihrem heutigen Server eine neue TFS 2010-Umgebung aufgesetzt. Wenn alles zu Ihrer Zufriedenheit fertig konfiguriert ist werden die Datenbanken auf das neue System kopiert und dort in das neue Format konvertiert.
Zu empfehlen ist ganz klar der zweite Weg! Gründe:
- 1: Bei einem "In-Place Upgrade" (Weg 1) gibt es keinen "Weg zurück" oder "Plan B" falls was schief geht
- 2: Mit einem parallel aufgesetzten neuen System (Weg 2) kann man die Ausfallzeiten gering(er) halten
- 3: Man startet mit einem sauberen System und hat die Möglichkeit neuste Technologien (Windows Server, SQL Server) von Grund auf einzusetzen
(TFS 2010 erfordert ohnehin den SQL Server 2008, der bei Weg 1 noch vorher installiert werden müsste).
ABER! Es gibt dennoch eine ganze Reihe an Stolpersteinen:
- A: Unbedingt vor dem Upgrade den von Microsoft veröffentlichen Hotfix installieren, sonst riskiert man evtl. Labels und Branch/Merge-Informationen zu verlieren! (Download hier).
- B: Je nach Größe der Datenbank ist ordentlich freier Festplattenspeicherplatz (das 1,5-fache der heutigen TFS-Datenbankgröße) erforderlich und der Upgrade-Vorgang kann einige Zeit in Anspruch nehmen (mehrere Stunden)
- C: Neben dem TFS müssen auch alle vorhandenen TFS Build Server und TFS Proxy Server auf die 2010er-Versionen aktualisiert werden. (Gerade bei den Buildservern hat sich vieles getan. Es sind nun Build Controller und Build Agents notwendig.)
- D: TFS 2010 erfordert mindestens Windows SharePoint Services (WSS) 3.0 bzw. MOSS 2007 mit Service Pack. Eventuell muss dieser also aktualisiert werden. Sofern oben Weg 2 (Installation auf eine neue Maschine) gewählt wurde, müssen die SharePoint-Services evtl. dann auf die neue Maschine umgebzogen werden (separate Anleitung).
- E: Der TFS 2010 wartet mit "Dashboards" und Cockpit-Ansichten auf um mehr Transparenz ins Dunkel des Projekts zu bringen. Dafür ist allerdings der SharePoint-Server in der Enterprise Edition von Nöten!
- F: Nach einem erfolgtem Upgrade nutzen die bestehenden Teamprojekte jedoch noch nicht die neue Funktionalität, da diese noch auf den alten Prozessvorlagen basieren. Um die neuen Features freizuschalten gibt es von Microsoft eine manuelle Anleitung, die – je nach Anzahl der Teamprojekte – einige Zeit beanspruchen kann: http://msdn.microsoft.com/en-us/library/ff432837(v=VS.100).aspx.
- G: Eigene Prozessvorlage müssen evtl. angepasst werden um die neuen Funktionalitäten zu berücksichtigen.
- H: Da die Buildprozesse völlig überarbeitet wurden (es wird nun die grafische Workflow Foundation aus dem .NET Framework 4.0 verwendet und zentrale unternehmensweite Buildskripte, die über Parameter angepasst werden) muss Zeit eingeplant werden die Buildskripte zu überarbeiten bzw. gänzlich neu zu erstellen. Generell gilt: je weniger Anpassungen man bisher vorgenommen hat, je weniger Buildprozesse eingerichtet waren, desto einfacher die Umstellung.
- I: Die Struktur des zentralen Berichtswesens (Data Warehouse, Cube, Reports) hat sich geändert: das bedeutet das die alten Berichte in der Regel nicht mehr funktionieren sowie Excelsheets, die auf den Cube zugegriffen haben, neu erstellt werden müssen (das gilt nicht für einfache Excel Sheets, die nur Work Items-Listen anzeigen). Microsoft liefert eine Vielzahl neuer interessanter Reports, für die man einige Zeit einplanen sollte um sie sich anzusehen, zu verstehen und letztlich effektiv einzusetzen.
- J: Es gibt sicherlich noch eine Reihe weiterer Themen, die noch zusätzlich betrachtet werden müssen. Auch neue Konzepte sollten im Team besprochen werden, so kennt die Versionsverwaltung nun zwei verschiedene Arten von Branches (neu sind so genannte "Branch Folder"), die sich in der Handhabung und gebotener Funktionalität unterscheiden.
- Nachtrag K: Auch sollte ein Upgrade nicht gleichzeitig verwendet werden um den Server in eine neue Domäne umzuziehen (dies ist ein separater Vorgang). Bei Domänenumzügen muss man darauf achten, dass erst die Benutzer neu zugeordnet werden müssen und erst dann der Server in der neuen Domäne benutzt werden darf, ansonsten droht ein unwiederbringbarer Zustand, bei dem die alten Benutzer nicht mehr den neuen entsprechen (auch wenn der Benutzername gleich ist).
Fazit: Das Upgrade funktioniert, doch es kann einiges an Zusatzaufwand entstehen.
Es lohnt sich also auf jeden Fall vor einem Upgrade einen Fachmann in die Planungen einzubeziehen*!
Viel Erfolg bei Ihrem Migrationsprojekt!
* Ein Erfahrungswert aus der laufenden Beratung: Der Aufwand für eine typische Migration (ohne speziellen Mehraufwand wie die Migration der Buildprozess-Skipte) samt einer kurzen Einführung in die neue Funktionalität liegt bei 2 Tagen.
Nachtrag (15.08.2010): Aus aktuellem Anlass Punkt Stolperstein K zur Liste oben hinzugefügt.
