© iStockphoto.com/5ugarless
Wie Sie die Migration problemlos durchführen

Von TFS XAML Build nach TFS Build


Seit mittlerweile zehn Jahren ist der Team Foundation Server (TFS) von Microsoft eine zentrale Plattform für den gesamten Softwareentwicklungsprozess. Das integrierte Build-System hat in der Version 2015 wieder eine Generalüberholung erlebt und wurde in allen Bereichen von Grund auf neu konzipiert. Es enthält viele neue und ebenso lang vermisste Features, sodass man sich als Nutzer des bisherigen XAML-Build-Systems einerseits die Frage der Notwendigkeit und andererseits eine Migrationsstrategie überlegen sollte. Das gilt für workflowbasierte Build-Prozesse ebenso wie für die altehrwürdigen TFSBuild.proj-Dateien auf MSBuild-Basis aus TFS-2005- und -2008-Zeiten.

Der Artikel gibt einen Überblick über die neue Struktur und die Besonderheiten in Konzept und Philosophie des neuen TFS-Build-Systems. Aufbauend auf diesen Informationen werden Migrationsstrategien von TFS XAML Build nach TFS Build vorgestellt und bewertet sowie Empfehlungen gegeben, sodass der Build-Nutzer seinen individuellen Weg von der alten zur neuen Generation besser findet.

TFS Build – die schöne neue Welt

Mit der Version 2015 des TFS hatte Microsoft ein neues Build-System eingeführt. Mittlerweile ist das nicht mehr so neue System erwachsen geworden, und auch für bezüglich neuer Technologien eher konservativ eingestellte Teams ist es an der Zeit, über einen Umstieg nachzudenken.

Doch warum war es eigentlich nötig, ein System radikal zu verändern, das so weit verbreitet war? Das „alte“ System basierte auf einer Workflow Engine, die technologisch auf Windows Workflow Foundation aufsetzte. Zum Entstehungszeitpunkt war das sicherlich eine gute Entscheidung, doch die Welt hat sich verändert. Im Laufe der Zeit haben sich einige Problemfelder aufgetan, die mit dem Wechsel adressiert werden sollten.

Als Erstes ist die begrenzte Skalierbarkeit der Infrastrukturkomponenten zu nennen. Die Arbeitsteilung zwischen Build Controller und Build Agent war zwar gut gemeint, hat sich aber durch ihre Struktur zu einem Flaschenhals entwickelt. Der hierarchische Zusammenhang (Abb. 1) von Team Project Collections über Build Controller bis hin zu Build Agents hat dazu geführt, dass die Build Controller zu einem Engpass wurden, der sich insbesondere in größeren Umgebungen schnell bemerkbar gemacht hat. Als Beispiele seien hier die Beschränkung auf einen Build Controller pro Rechner oder die fehlende Flexibilität bei Build-Job-Warteschlangen genannt.

orschel_ruemmler_tfs_1.tif_fmt1.jpgAbb. 1: „Alte“ Build-Server-Architektur

Als Nächstes ist zu nennen: ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang