In diesem Beitrag wird das Standard-Upgrade von Team Foundation Server 2010 auf die neuste Version 2012 (Single-Server) und ein dafür nötiges Upgrade des SQL Server 2008 detailliert erklärt…
Ausgangspunkt dieses Artikels ist ein TFS 2010 und ein SQL Server 2008. Beide befinden sich auf derselben Windows Server 2008 R2-Maschine. Die Reporting- und Analysisdienste sind auf demselben SQL-Server installiert, was einem Single-Server entspricht. Eine SharePoint-Anbindung ist nicht vorhanden. Beachten Sie, dass Ihr Build-Server gegebenenfalls auch aktualisiert werden muss. Dies wird am Ende des Artikels ebenfalls kurz behandelt.
Hinweis
Dieser Artikel soll Ihnen einen Eindruck vom Umfang eines Standard-Upgrades in der Vairante Single-Server, Inplace-Upgrade geben. Teilweise werden Local-Service- oder Administrator-Accounts verwendet, die Sie so nicht in Ihrer Produktivumgebung einsetzen sollten. Eine Liste der Vorbereitungen inkl. benötigter Service-Accounts zum Download finden Sie hier:
Weitere Informationen erhalten Sie in der MSDN und dem aktuellen TFS 2012 Installation Guide.
Voraussetzungen
Um überhaupt ein Upgrade ausführen zu können, benötigen wir folgende Installationsmedien:
- Installationsdateien von SQL-Server 2008 R2
- Installationsdateien von Team Foundation Server 2012 (aktuelles Update inkl. Hotfix)
- Zugangsdaten für die lokalen Benutzerkonten von Team Foundation Server und SQL
- Product-Key für SQL Server 2008 R2
- Product-Key für Team Foundation Server 2012
Backup der Datenbank
Zuerst müssen wir ein Backup der Datenbank von TFS 2010 durchführen, um in Notfall den alten Datenstand wiederherstellen zu können. Zudem sollte auch der SQL Server Reporting Services Encryption Key gesichert werden, falls das Reporting genutzt wird.
Im Falle einer Single-Server-Instanz sollten die TFS-Verbindungen ab diesem Schritt gekappt sein, damit niemand nach dem Backup noch Dateien eincheckt oder ähnliches.
SQL Server 2008 Upgrade
Da TFS 2012 mindestens eine SQL Server 2008 R2-Instanz zwingend voraussetzt, müssen wir zunächst ein Upgrade von SQL-Server 2008 auf SQL-Server 2008 R2 durchführen. Dazu starten wir das SQL-Server-Setup und wählen „Upgrade from SQL Server 2000, SQL Server 2005 or SQL Server 2008“.
Bevor es weiter geht, wird vom Setup überprüft, ob die Voraussetzungen für das Upgrade erfüllt sind. Danach muss der Product-Key eingegeben werden und die Lizenzvereinbarungen akzeptiert werden. Mit einem Klick auf „Install“ beginnt das Upgrade.
Zu Beginn wird wiederum verifiziert, dass alle Regeln für das Upgrade erfüllt sind. Falls eine Regel nicht erfüllt ist, können die dafür benötigten Aktionen durchgeführt werden. Mittels „Re-run“ können die Regeln nochmals überprüft werden, ohne dass der Upgrade-Vorgang von vorne beginnen muss.
Auf der „Select Instance“-Seite wird die SQL-Server-Instanz ausgewählt, welche aktualisiert werden soll. In unserem Fall ist dies die Default-Instanz „MSSQLSERVER“.
In der Seite „Select Features“ wählen wir die Features für den SQL-Server aus.
Dazu gehören:
- Database Engine
- SQL Server Reporting Services (Falls Reporting genutzt werden soll)
- SQL Server Analysis Services (Falls Reporting genutzt werden soll)
- Client Management Tools (SQL Management Studio und Business Intelligence Studio)
Es folgt eine Überprüfung des freien Festplattenplatzes.
Unter „Service Configuration“ kann das Servicekonto der SQL-Instanz angegeben werden. Wir ändern die Vorgabe zur Vereinfachung jedoch nicht.
Danach wählen wir „Rebuild“ als Methode für das Upgrade des Volltexts aus.
Im darauffolgenden Abschnitt kann die Instanz und das Konto für den Reporting-Dienst angegeben werden. Wir belassen es wieder bei der Vorgabe.
Kurz vor dem Upgrade werden einige Regeln überprüft. Falls eine Regeln nicht bestanden hat, kann diese nach Änderungen mittels „Re-run“ überprüft werden.
Nachdem alle Regeln bestanden sind, bekommen wir die vorgenommene Konfiguration zu sehen. Über den Button „Upgrade“ starten wir nun das Upgrade.
Das SQL-Server-Upgrade ist nun fertig. Wir müssen noch das System neu starten.
Installation des Service Packs 1 und Hotfixes
Nach dem erfolgreichen Upgrade muss noch Service Pack 1 installiert werden. Ein Neustart des Systems schließt diese Installation ab. Zu guter Letzt müssen noch weitere Hotfixes installiert werden:
[1] http://support.microsoft.com/kb/2528583
[2] http://go.microsoft.com/fwlink/?LinkId=240305
Verifizierung
Zur manuellen Überprüfung des Upgrade-Vorganges können wir das Upgrade nochmals starten und zur Seite „Select Instances“ gehen. Ein Blick auf die Spalte Version in der Reihe „MSSQLSERVER“ verrät uns die neue Nummer, dass die Instanz SQL Server 2008 R2 verwendet.
TFS 2010 Deinstallation
Bevor TFS 2012 installiert werden kann, muss TFS 2010 deinstalliert werden. Der Befehl „appwiz.cpl“ öffnet das Fenster zum Deinstallieren von Programmen. Die Deinstallation erfolgt über den Eintrag „Microsoft Team Foundation Server 2010 – ENU“:
Abschließend sollten auch noch zusätzliche Programme in Bezug auf TFS 2010 deinstalliert werden. Diese können zum Beispiel Microsoft Team Foundation Server 2010 Build Extensions, Microsoft Team Foundation Server 2010 Object Model – ENU und Microsoft Team Foundation Server 2010 Power Tools sein. Die Anleitungen der jeweiligen Software muss beachtet werden.
TFS 2012 Installation
Nach der erfolgreichen TFS 2010-Deinstallation, kann nun die Installation von TFS 2012 beginnen. Dazu führen wir „tfs_server.exe“ im Hauptverzeichnis der Installations-DVD aus:
Es startet das Team Foundation Server Configuration Center. Die Installation läuft und endet schließlich mit einer Erfolgsmeldung. Entfernen Sie den Haken bei “Launch configuration wizard”. Es müssen zunächst noch Hotfixes (siehe oben) installiert werden.
Danach kann man im Start-Menü die “Team Foundation Administration Console” starten und den „Upgrade“-Wizard starten:
Nach der Welcome-Seite gelangen wir in die Databases-Seite. Hier müssen wir die zu verwende SQL-Server-Instanz auswählen. Mit einem Klick auf „List Available Databases“ erscheinen die Datenbanken. Wir wählen die Datenbank „Tfs_Configuration“ aus. Danach bestätigen wir durch den Haken „By checking this box, I confirm that I have a current backup.“, dass wir unsere Datenbank bereits gesichert haben. Falls dies nicht so ist, kann über den darüber liegenden Link eine Sicherung durchgeführt werden.
Auf der nächsten Seite „Application Tier Settings“ wird das Konto für den Application-Tier angegeben, in unserem Fall ist dies das Systemkonto „NT AUTHORITY\LOCAL_SERVICE“.
Weiter geht es an die Einstellungen für das TFS-Reporting.
In der Seite „Reporting Services“ geben wir die Reporting-Instance und die Report-Server-URL und Report-Manager-URL an.
Unter „Databases“ wählen wir die Warehouse-Datenbank aus:
Jetzt richten wir die Analysis-Dienste ein. Dazu geben wir die SQL-Server-Analysis-Service-Instanz an. Über den Test-Link können wir verifizieren, dass diese erreichbar ist.
Auf der Seite „Report Reader Account“ füllen wir die Felder für das Konto zum Zugriff auf die SQL-Server-Report-Services aus. Mittels dem Test-Link können wir wiederum überprüfen, ob dieser Zugriff erfolgreich ist.
Da SharePoint nicht an unseren TFS angebunden ist, bzw. nicht angebunden wird, müssen wir sicherstellen, dass der Haken „Configure SharePoint for use with Team Foundation Server“ nicht gesetzt ist. Die Integration kann jedoch nachträglich zu einem beliebigen Zeitpunkt durchgeführt werden.
Nun bekommen wir alle Einstellungen auf einer Seite präsentiert:
Im darauf folgenden Readiness-Check wird nochmals überprüft, ob alle Einstellungen in Ordnung sind. Mit einem Klick auf „Configure“ startet die Konfiguration, danach beginnt das ersehnte Upgrade. Dieser Vorgang kann je nach Größe der Team Collection unterschiedlich lang dauern.
Nach dem Upgrade-Vorgang bekommen wir die Bestätigung, dass das Upgrade erfolgreich durchgeführt wurde.
Hinweis: Je nach Größe der Datenbanken, kann dieser Schritt (insbesondere Teilschritt 13 “Version Control” sehr lange dauern ohne einen Fortschritt zurückzumelden. Solange keine Fehlermeldung erscheint ist alles in Ordnung – Sie brauchen nur etwas Geduld.
Abschließend bekommen wir noch einen Überblick des Ergebnisses.
Neue Funktionen in Teamprojekten freischalten
Doch damit ist nur das Schema der Datenbanken auch tatsächlich aktualisiert. Die damit bereits aktiven neuen Funktionen sind:
- Das Description Feld in Work Items ist Rich Text (inkl. Möglichkeit Bilder einzufügen)
- Discussion View in Work Item History (Filter auf Kommentare oder alle Änderungen – auch für die bestehende Historie)
- Neues Web Access mit Teams und Team-Portalen
Die Teamprojekte sind noch unberührt auf dem Funktionsumfang von TFS 2010. Somit werden ohne weitere Schritte die folgenden neuen Funktionen von TFS 2012 nicht unterstützt:
- Team Explorer: My Work
- Team Explorer: Code Review
- Web Access: Agile Planning Tools
- Web Access: Feedback Request (Nicht Express)
- UI Storyboarding: Links zu Work Items
- Source Control: Local Workspace
- Build: Testintegration für nicht-MSTests
- Build: Ausführung der Builds auf Build-Agents (diese müssen ebenfalls auf 2012 angehoben werden)
Für das Aktivieren eines Großteils dieser Funktionen dient der Assistent im Web Access:
Diesen finden Sie in den Einstellungen des Teamprojekts. Nach dem Start wird versucht, das Process Template des Teamprojekts auf den neuen Versionsstand zu heben.
Das kann aber nur bei kaum veränderten Process Templates erfolgreich laufen. In anderen Fällen müssen die Änderungen manuell nachgepflegt oder im Rahmen unserer Upgrades per Skript (z.B. bei vielen Teamprojekten) aktualisiert werden. Weitere Informationen zum geführten Upgrade…
Was genau an den Process Template neu ist kann man in der MSDN unter “What’s new in Planning and Tracking” nachlesen. Zusätzlich müssen die Agilen Planungstools freigeschalten werden (Nicht in Express enthalten!).
Ist der Assistent erfolgreich durchgelaufen, kann man die Warnmeldung im Team Explorer My Work-Tab getrost ignorieren:
Nun fehlt noch der Local Workspace. Im Tab Pending Changes des Team Explorers kann man einen vorhandenen Workspace umstellen:
Weitere Informationen zu Local Workspaces…
Nach wenigen Sekunden ist der Workspace für die Offline-Arbeit vorbereitet.
Team Foundation Build umstellen
Die Umstellung der Builds ist mehr oder minder problematisch. Das DefaultTemplate wird nach Aktualisierung der Build-Agents auf die neue Version möglicherweise nicht mehr funktionieren:
Eine Umstellung auf das neue DefaultTemplate.11.xaml ist nötig. Sollten Sie Anpassungen gemacht haben, müssen diese gegen das neue .NET Framework 4.5 kompiliert werden. Berücksichtigen Sie außerdem, dass Windows XP Build-Rechner nicht mehr unterstützt werden!
Die neue Version der AIT Build Suite können sie demnächst hier beziehen.
Weitere Informationen
Sollten Sie weitere Fragen zum Upgrade haben oder es durch uns Durchführen lassen möchten, scheuen Sie sich nicht davor, mit uns in Kontakt zu treten: [email protected]
Beachten Sie auch unser Sonderangebot für ein TFS-Upgrade: Flyer herunterladen
Hallo,
ein wirklich guter Beitrag. Besonders gut gefallen hat mir das in diesem Beitrag auch über das “normale” Upgrade des TFS (Installation u. Upgrade der DB) hinaus einige Punkte erläutert werden.
Sehr interessiert war ich hier an dem “Team Foundation Build umstellen” u. dem Umstellen auf die “local Workspace”.
Bezüglich der local Workspaces habe ich eine Frage. Kann es sein das dieses Feature sehr auf die Performances des Source Control Explorers geht? Seit dem ich mein Workspace auf local workspace umgestellt habe dauert es extrem lange wenn ich einen Ordner im Source Control Explorer öffne.
Mit freundlichem Gruß
Mirko Venker
Hallo Herr Venker,
in der Tat hängt die Performance der Local Workspaces von der Anzahl der im Workspace liegenden sprich “überwachter” Dateien. Das können Sie umgehen, in dem Sie Ihre Workspace-Mappings nicht auf Ebene des Teamprojektes setzen, sondern auf einem Branch-Folder. Sollte es sich nicht dadurch beheben lassen, hilft evtl. ein Rücksprung auf den Server-Workspace. Die Einstellung finden Sie bei “Edit Workspace…” unter “Advanced…” in der Einstellung “Location”.
Mit freundlichen Grüßen,
Sven Hubert