Build Prozesse bilden das Fundament moderne Entwicklungsprozesse und ein Sicherheitsnetz für viele Entwicklerteams. Schlagwörter wie Continous Integration und Continous Delivery sind aus dem Entwickler-Sprachgebrauch nicht mehr wegzudecken. Build Prozesse werden hierbei für vielfätige Dinge eingesetzt, Übersetzung der Software, Versionierung, Integration und Prüfung der geänderten Sourcen, Testen, Erstellung von Setups, Deployments, Ausführung von automatischen Tests etc..
In der TFS Plattform ist das Build-System bereits seit der ersten Version (TFS 2005) ein essenzieller Bestandteil. Auch die Build-Plattform hat wie der TFS über die Jahre vielfältige Änderungen erlebt. In den TFS Versionen 2005 und 2008 basierte der komplette Prozess noch vollständig auf MSBuild (TFSBuild.proj). Mit TFS 2010 wurde die Steuerung des Arbeitsablaufs auf die .NET Workflow Foundation umgestellt. Es wurden dadurch völlig neue Möglichkeiten eröffnet. Entwickler waren erstmals nicht mehr auf rein sequenzielle Abläufe limitiert. TFS 2012 brachte hier anschließend kleinere Detailverbesserungen.
Im nächsten TFS 2013 Release stehen jetzt wieder größere Änderungen an. Auf die einzelnen Änderungen und Anwendungsmöglichkeiten wird in den folgenden Kapiteln eingegangen.
Was ist neu?
– Stark vereinfachtes Workflow Template / Vereinfachte Build Konfiguration
Viele Entwickler haben in den vergangenen Jahren Build Workflow Templates an Ihre Bedürfnisse angepasst. Im Zusammenhang mit den Anpassungen gab es in der Praxis dabei oft zwei Probleme:
- Unübersichtlichkeit durch komplexen Workflow und
- Workflow Editor bei komplexen Workflows teilweise langsam.
TFS 2010/2012 Workflow:
Mit TFS 2013 hat sich die Produktgruppe der Verschlankung des Workflows angenommen. Anstatt wie bisher (> 30 Workflow Activities) verfügt der neue Workflow nur noch über 8 Basisaktivitäten (siehe nachfolgender Screenshot). Diese neuen acht Aktivitäten bilden jetzt zusammengefasst die Funktionalität der “alten” Aktivitäten ab.
TFS 2013 Workflow:
Im Rahmen der Verschlankung wurde neben den Aktivitäten auch die Build-Prozess-Einstellungen (siehe Option Process) einer Überarbeitung unterzogen. Die neuen Build-Einstellungen wirken wesentlich aufgeräumter und übersichtlicher.
TFS 2010/2012 Process Einstellungen:
TFS 2013 Process Einstellungen:
– GIT Support
Mit dem TFS 2013 unterstützt Microsoft erstmals GIT als weiteres Versionskontrollsystem (siehe GIT Blogartikel). Neben dem Client-seitigen GIT Support verfügt jetzt auch das Build-System über eine entsprechende Unterstützung mit. Prinzipiell sind damit TFVC (Team Foundation Version Control) und GIT an Funktionalität gleichauf. Aktuell werden bei GIT Builds lediglich Gated Checkins nicht unterstützt.
– Eigene Ausgabeordner (Output Folder)
Seit den ersten TFS Build-Server Versionen leitet der TFS Build-Prozesse ihre Buildergebnisse in vorgegebene Standardverzeichnisse um (Binaries Output Ordner). Das Ergebnis war, dass alle Dateien unabhängig vom Projekt in einem Verzeichnis abgelegt wurden. Mit TFS 2012 wurde eine Option eingeführt mit dem die Ausgaben pro Solution abgelegt werden konnten. Im aktuellen TFS 2013 Release können Sie jetzt die Ausgabeumleitung komplett deaktivieren (Option: “As configured”). Als Ergebnis haben Sie jetzt die komplette Kontrolle über die Organisation Ihrer Build-Ausgabeordner.
– Skript Unterstützung
In Build-Prozessen gibt es oft die Notwendigkeit kleinere Aktionen vor, nach oder während eines Builds auszuführen. Die Bandbreite der Aktionen reicht dabei vom einfachen Kopieren, Verschieben oder Löschen von Dateien bis zum Ausführen von 3rd Party Programmen. Im klassischen Workflow (TFS 2010, TFS 2012) waren dafür eigene Anpassungen zur Integration notwendig (siehe z.B. Extension Points der AIT Build Suite). Die neuen 2013 Build Templates ermöglichen jetzt die Ansteuerung von eigenen Skripten (z.B. Batch Datei, PowerShell Skript) vor/nach Ausführung von MSBuild und vor/nach der Ausführung des Testrunners. Dem jeweiligen Skript stehen bei der Ausführung verschiedene Build-Parameter über Umgebungsvariablen zur Verfügung (z.B. Binaries oder Source Verzeichnis).
– Source Control als Drop Location / Download als Zip Datei
Build Ergebnisse werden seit der ersten TFS Version in Windowsfreigaben abgelegt und verteilt. Am Ende eines jeden Build-Prozesses kopiert der Buildserver die Ergebnisse auf eine Windows Freigabe. Mit der Veröffentlichung von Team Foundation Service bestand jetzt auch die Möglichkeit die Build-Ergebnisse in einem Source Control Verzeichnis (“Copy build output to the following Source Control folder”) oder direkt im TFS Server (“Copy build output to server”) abzulegen. Diese zwei neuen TF Service Möglichkeiten der zentralen Ablage von Build-Ergebnissen stehen jetzt für lokal installierte TFS Instanzen zur Verfügung.
Werden Build-Ergebnisse direkt im TFS Server gespeichert, dann können Sie jetzt diese als Zip Datei direkt vom TFS herunterladen.
– Standard Templates
In den vergangenen TFS Versionen war es üblich das Build-Skripte bzw. Build-Workflow-Templates unterhalb eines Team Projektes bzw. Branches abgelegt wurde. Sehr oft gibt es die Situation, dass Anwender nur mit dem Standard-Template ohne Modifikationen arbeiteten. Das Problem aus Source Control Sichtweise war hier, dass Build-Templates unnötig oft redundant im TFS gespeichert wurden. TFS 2013 adressiert dieses Problem durch Einführung von Standard-Templates (ein GIT Template und ein TFVC Template). Die neuen Standard-Templates stehen dabei zentral und unabhängig von der verwendeten Versionskontrolle allen Projekten zur Verfügung. Benötigt der Anwender eine modifizierte Version, dann werden diese, wie bei den Vorgängerversionen über die Source Control gepflegt.
TFS 2010/2012 Build Templates:
TFS 2013 Standard Build-Templates (GIT + TFVC):
– Windows 8.1 Apps
Das Build System unterstützt die Übersetzung von nahezu allen Visual Studio Projekttypen ohne weitere Anpassungen. In den meisten Projekten reicht die Angabe einer Visual Studio Projekt- oder Solution-Datei aus und den Rest der Arbeit übernimmt ein Gespann aus MSBuild und .NET Workflow. Als kleinere Neuerung bei TFS 2013 bringt dieses Gespann jetzt eine native Unterstützung für Windows 8.1 Apps mit. Dies bedeutet, dass Sie Windows 8.1 Apps mit einem Build-Server automatisiert übersetzen können.
Fazit
Am Build-System wurden vielfältige Änderungen vorgenommen. Neben neuen Features (GIT Support) und der Vereinfachung und Verschlankung des Build-Workflows wurden viele kleine Probleme aus der Praxis als Out-of-the-Box veröffentlicht (Build-Ergebnisse als Zip Datei oder Source Control Ordner, Eigene Ausgabe Ordner , Skriptunterstützung). Die neuen Änderungen werden auf jeden Fall die Einführung von neuen Build-Prozessen bzw. die Wartung von existierenden Build-Prozessen vereinfachen.
TFS 2010/2012 Workflow: soll man da irgendwas erkennen können? 🙂