Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Sven Hubert

Sven Hubert

Migration von Team Build 2008 auf Team Build 2010

Donnerstag, 06. Mai 2010

Wie kann ich meine angepassten Build-Prozesse in Form von TFSBuild.proj-Dateien auf das neue Team Build 2010 migrieren?

Wer mit TFS 2008 eine Build-Infrastruktur aufgebaut hat und zahlreiche Prozess aufgesetzt und angepasst hat, sollte ein Upgrade auf den neuen Team Foundation Server 2010 genau planen. Die folgenden Schritte sollen helfen, nichts zu vergessen und sich auf die Migration vorzubereiten.

Upgrade der gesamten Infrastruktur

Prinzipiell müssen alle Build-Komponenten des TFS auf die neue Version aktualisiert werden. Das betrifft also alle Build-Maschinen sowie natürlich TFS App und Data Tier.

Die Build-Komponenten befinden sich auf dem TFS 2010-Installationsmedium.

Automatisches Upgrade der Build-Definitionen

Während des Upgrades der Datenbanken des TFS 2008 auf TFS 2010 werden alle Build-Definitionen beibehalten und mit dem BuildProcessTemplate “UpgradeTemplate.xaml” hinterlegt. Das Template sorgt dafür, dass der Build-Prozess auf Basis des zentral auf den Build-Maschinen ausgerollten MSBuild-Skripts Microsoft.TeamFoundation.Build.targets ausgeführt wird – was dem Vorgehen von Team Foundation Build 2008 entspricht. Die Parameter sind entsprechend eingestellt, sodass während des Builds die entsprechende TFSBuild.proj-Datei die im Rahmen des Source Control-Upgrades bereits übernommen wurde.

Unbedingt beachten

Überprüfen Sie im Anschluss an das Upgrade unbedingt die Retention Policy der Builds. Im Zweifelsfall kann es dazu kommen, dass alle Ihre Builds bei ausgeschalteter Retention Policy mehr Daten in den TFS ablegen. So werden Testergebnisse und Test-Binaries in TFS 2010 nicht nur in der Drop-Location sondern auch in der Datenbank abgelegt.

Lokale Build (früher: Desktop-Builds)

Zukünftige Anpassungen sollten entweder in Form von Custom Activities mit in das BuildProcessTemplate.xaml eingebunden werden, sofern der eigentliche Kompilier- bzw. lokale Bauvorgang nicht davon betroffen ist. Alles was mit dem Kompilieren und lokalen Bauen auf Entwicklermaschinen zu tun hat, sollten in Form ausführbarer Skripte innerhalb der Solution bzw. des Solution-Ordners hinterlegt sein. Den Desktop-Build aus Team Build 2008 gibt es so nicht mehr. Dieser wurde durch den sogenannten Private- oder Buddy-Build ersetzt, bei dem ein Shelvseset mit den lokalen ausstehenden Änderungen auf dem Build-Agent (z.B. auch dem Entwicklerrechner selbst) “verbaut” wird.

Weitere Hilfestellungen

…bieten wir Ihnen gerne auf Anfrage an teamsystempro@aitag.com.

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Hinterlasse eine Antwort