© iStockphoto.com/5ugarless
Windows Developer
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.

Nico Orschel, Thomas Rümmler


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.

Abb. 1: „Alte“ Build-Server-Architektur

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 Founda­tion so eng an die Windows-Welt gekoppelt, dass es in...

Windows Developer
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.

Nico Orschel, Thomas Rümmler


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.

Abb. 1: „Alte“ Build-Server-Architektur

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 Founda­tion so eng an die Windows-Welt gekoppelt, dass es in...

Neugierig geworden?


    
Loading...

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