Wie Sie die Migration problemlos durchführen
Von TFS XAML Buld nach TFS Build - windows.developer 03/2017
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.
Als Nächstes ist zu nennen: der heterogene Technologiemix bei den Entwicklern auf der einen, und die enge technologische Bindung der Build-Plattform an die Windows-Welt auf der anderen Seite. Die Steuerungsebene über dem Compiler MSBuild, die durch die Windows Workflow Foundation definiert wurde, hat über die Zeit hinweg so einige Schwierigkeiten hervorgebracht. Zum einen war der Initialaufwand, sich in die Workflow-Engine einzuarbeiten, relativ hoch. Selbst wenn man in die Thematik eingearbeitet war, hatte man es, z. B. als Drittanbieter, nicht gerade leicht, den Workflow zu erweitern. Darüber hinaus war man mit der Windows Workflow Foundation so eng an die Windows-Welt gekoppelt, dass es in der bunten Welt verschiedenste Technologien von guten bis abenteuerlichen Lösungen gab, um z. B. Linux Builds mit zu verwalten. Eine enge technologische Kopplung hatte man auch noch zur eingesetzten Visual-Studio-Version. So war eine Build Definition nur zu bestimmten Visual-Studio-Versionen kompatibel, ganz zu schweigen von der Hürde, den Workflow im XAML-Editor in Visual Studio zu öffnen. Die Abhängigkeiten mündeten dann nicht zuletzt in einem relativ schwergängigen Updateprozess. Jede Build-Maschine musste von Hand aktualisiert werden. Das Ganze aber auch erst dann, wenn alle verwendeten Komponenten mit der neuen Version kompatibel waren.
Nicht zu vergessen ist auch das Rechtemanagement:
Um dem TFS einen neuen Build-Server bekanntmachen zu können, war die administrative Latte ziemlich weit oben aufgehängt. Man musste Team Project Collection Administrator sein, um dies durchführen zu können. Für eigenständige Entwicklungsteams kann das eine ziemliche Produktivitätsbremse sein. Es geht hier nicht darum, dass jeder neue Build-Server für den Release-Build erstellen kann. Aber für den Development-Branch kann es schon sinnvoll sein, einen neuen Build-Server zu verwenden, z. B. um eine neue Drittherstellerkomponente auf einem „sauberen“ System zu verwenden zu können.
Mit dem „neuen“ Build-System hat sich Microsoft von diesen Problemen verabschiedet. Deshalb ist es technologisch wie auch architektonisch ein Bruch mit der alten Welt. Es fängt damit an, dass XAML als eigene Build DSL (Domain Specific Language) in diesem Umfeld keine Rolle mehr spielt. Durch die Definition über einzelne Build Tasks im Webbrowser, die in sich technologisch relativ unabhängig sind und mittlerweile von einem echten plattformübergreifenden Agenten ausgeführt werden, ist der Multiplattformansatz vollständig.
Auch die Erweiterbarkeit ist mittels leicht zu verwendender Schnittstellen gelöst. Im einfachsten Fall verwendet man PowerShell oder JavaScript, um eigene Logik im Build-Prozess abzubilden. Es gibt in diesem Umfeld auch schon eine Menge an Communityaktivität [1], sodass man den eigenen Katalog an möglichen Build Tasks (Abb. 2) massiv erweitern kann – ohne nur eine einzige Zeile selbst dafür programmieren zu müssen. Diese fertigen Build Tasks können anschließend relativ einfach über eigene oder Build-System-Standardvariablen gesteuert werden…