Mit TFS 2015 wurde ein komplett neues Build- und Releasemanagement-System eingeführt. Über einen Teil der enthaltenen Neuerungen, wie z.B. das Importieren und Exportieren von Builddefinitionen konnten Sie bereits in vorhergehenden Beiträgen unserer Blogserie lesen. In diesem Blogpost möchten wir Ihnen nun einen weiteren großen Schritt vorstellen, den Microsoft im Ausbau des neuen Systems geht: Task Groups.
Jede Build- und jede Releasedefinition besteht aus einer Menge an Tasks, welche nacheinander ausgeführt werden. Jeder dieser Tasks definiert dabei eine auszuführende Aktion, wie z.B. das Bauen einer Anwendung, das Ausführen von Tests, u.v.m. In vielen Fällen wird die gleiche Abfolge an Tasks in mehreren Build- oder Releasedefinitionen verwendet um z.B. firmenspezifische Abläufe abzubilden, und unterscheidet sich dabei nur durch die Parameterwerte, welche als Input an den einzelnen Tasks spezifiziert werden. In diesem Fall bieten Task Groups eine einfache Möglichkeit, die Definition und Eigenschaften von solchen Abfolgen zentral zu verwalten. Task Groups fassen also eine Reihe von Tasks zusammen und stellen diese dann als einen einzigen, wiederverwendbaren Task den Build- und Releasedefinitionen zur Verfügung. Dies birgt folgende Vorteile:
- Zentralisierung von wiederkehrenden Abläufen
- Verringerung von Redundanzen
- Änderungen an Task Groups werden auf alle Definitionen angewendet, welche die Task Group referenzieren
- …
Um eine neue Task Group anzulegen, kann innerhalb einer Build- oder Releasedefinition eine Abfolge an Tasks ausgewählt werden und anschließend im Kontextmenü der Eintrag Create task group gewählt werden (vgl. Abb. 1).
Abbildung 1: Erstellen einer Task Group
Beim Anlegen sind folgende Punkte zu beachten:
- Task Groups sind Team Projekt-spezifisch.
- Für die zu erstellende Task Group muss ein Name spezifiziert werden (vgl. Abb. 2 (1)) sowie die Gruppe des Task Katalogs, in welchem die Task Group enthalten sein soll (vgl. Abb. 2 (3)). Des Weiteren kann eine Beschreibung angegeben werden. (vgl. Abb. 2 (2)).
- Alle Parameterwerte, welche innerhalb der einzelnen Tasks verwendet werden und durch Variablen spezifiziert sind, werden automatisch auch als Variablen an der Task Group abgebildet. Der zugehörige Variablenwert wird als Default-Wert gesetzt, kann jedoch im Nachhinein noch geändert werden (vgl. Abb. 2 (4)).
- Alle Parameterwerte, welche innerhalb der einzelnen Tasks verwendet werden und durch fest Werte (d.h. keine Variablen spezifiziert sind) werden auch als feste Werte für die Task Group übernommen. Diese fixen Werte können beim Referenzieren der Task Group nicht von außen angepasst werden.
- Aus den beiden vorhergehenden Punkten folgt: Alle Parameterwerte, welche beim Referenzieren der Task Group veränderbar sein sollen, müssen als Variable in den enthaltenen Tasks definiert sein.
Abbildung 2: Eigenschaften beim Erstellen einer Task Group
Nach der Erstellung können Task Groups zentral im Task Groups-Tab des Build & Release-Hubs verwaltet und editiert werden. Jede Task Group verfügt darin vier Tabs:
- In den Properties können die allgemeinen Eigenschaften Name, Description und Category angepasst werden. Darüber hinaus sind alle Task Group Variablen mitsamt ihrer Defaultwerte und Beschreibungen enthalten.
- Der Tab Tasks enthält die Abfolge der Tasks. Hier können fixe Parameterwerte zu Variablen geändert werden, neue Tasks hinzugefügt werden, …
- Im Tab History können alle Änderungen, welche an der Task Group vorgenommen wurden, nachverfolgt und untereinander verglichen werden (vgl. Abb. 3).
- Der Tab References enthält die Liste alle Build- und Releasedefinitionen sowie alle Eltern-Task Groups, welche die Task Group referenzieren.
Abbildung 3: Änderungsnachverfolgung in Task Groups
Der History-Tab einer Task Group bietet schon einige Sicherheit bei Änderungen. Da sich Änderungen an einer Task Group jedoch sofort in allen Build- und Releasedefinitionen durchschlagen ist das Risiko von unerwünschten Effekten immer noch relativ hoch. Dies kann durch die Verwendung von Versionierung weiter reduziert werden: Änderungen an Task Groups können zunächst als Draft abgespeichert werden (vgl. Abb.4 (1)). Damit kann die letzte stabile Version zunächst weiter in den bestehenden Prozessen verwendet werden und die Änderungen nur in ausgewählten Definitionen getestet werden. Nach erfolgreichem Testen der Änderungen können diese dann in die ursprüngliche Task Group gepublished werden (vgl. Abb. 4 (2)). Änderungen, welche nicht abwärtskompatibel sind, können dabei als Preview gepublished werden. Dies erzeugt eine neue Version der Task Group. Damit können verschiedene Versionen einer Task Group zur selben Zeit im Einsatz sein. Die Preview-Version kann dann zu einem späteren Zeitpunkt wiederum als offizielle neue Version gepublished werden.
Abbildung 4: Versionierung von Task Groups via Drafts
Abgerundet wird das Konstrukt durch die Möglichkeit Task Groups zu exportieren (vgl. Abb. 5 (1)) und Importieren (vgl. Abb. 5 (2)). Oftmals werden Änderungen an Prozessen zunächst in einer separaten Testinstanz durchgeführt und getestet. Es existieren auch Build- und Releaseabläufe, welche über den Team Projekt-Kontext hinweg gleich sind. Durch den Export und Import von Task Groups entfällt in solchen Szenarien die Notwendigkeit dieselben Änderungen an verschiedenen Stellen machen zu müssen und eliminiert damit auch das Risiko von Fehlern beim manuellen Übertragen von Änderungen.
Abbildung 5: Export und Import von Task Groups
Fazit
Das Konzept von Task Groups bietet eine schöne und durchdachte Möglichkeit wiederkehrende Abfolgen in Build- und Releasedefinitionen zentral zu definieren und zu verwalten. Das mit TFS 2015 neu eingeführte System macht damit einen weiteren großen Schritt auf dem Weg zum Erwachsenwerden.
Weitere Schritte auf diesem Weg stellen wir Ihnen auch in nachfolgenden Beiträgen unserer Blogserie vor. Bleiben Sie also dran und freuen Sie sich auf spannende Neuerungen mit TFS 2018.