Extensions bieten die Möglichkeiten den TFS um weitere Funktionalität an vordefinierten Stellen, sogenannten Extension Points, zu erweitern. Im Build- und Releasemanagement gibt es hierfür einige Anwendungsfälle: zusätzliche Menüeinträge an Build- und Release Definitionen, eigene Tasks, zusätzliche Informationen in Build- und Release Zusammenfassungen (Build- und Release Summary), u.v.m.
In vorhergehenden Beiträgen unserer Blogserie “Neu in TFS 2018” wurden bereits einige spannende Neuerungen für das Build- und Releasemanagement für die neueste Major Version des TFS, wie z.B. Task Groups, beschrieben. Mit diesem Blogbeitrag möchten wir Ihnen nun die Neuigkeiten für Extension-Entwickler(innen) in diesem Bereich näherbringen sowie zwei Neuerungen für server-seitige Tasks im Release Management.
Build
Bereits seit Einführung des JSON-Buildsystems existieren Build Templates, welche häufig verwendete Tasks für bestimmte Szenarien wie z.B. das Bauen einer .NET Desktop Anwendung zusammenfassen. Diese können als Ausgangspunkt für Buildprozesse verwendet werden und z.B. durch Hinzufügen und Entfernen von Tasks für eigene Zwecke weiter angepasst werden.
Vor allem in größeren Firmen existieren oftmals standardisierte Abläufe, welche sich in mehreren Buildprozessen wiederspiegeln jedoch durch die vorgegebenen Build Templates nicht abgedeckt werden. Hierfür ist es hilfreich diese Abläufe mittels eigener Build Templates abbilden und zur Verfügung stellen zu können. TFS 2018 bietet nun erstmals die Möglichkeit eigene Templates auch über VSTS Marketplace Erweiterungen (VSIX Dateien) zu verteilen. In den Erweiterungs-Metadaten ist hierzu ein neuer Extension Point ms.vss-build.template (vgl. Snippet 1) eingeführt worden. Ein vollständiges Beispiel für solch eine Extension ist in GitHub zu finden.
{ "id": "AIT Build Template", "type": "ms.vss-build.template", "targets": [ "ms.vss-build.templates" ], "properties": { "name": "AIT Build Template" }
}
Snippet 1: Auszug aus der Definition eines Custom Build Templates
Eine weitere Neuerung im Bereich der Build Erweiterungen ist die Möglichkeit eigens definierte Abschnitte in Build Zusammenfassungen ein- und auszublenden. Bisher wurden solche Abschnitte immer angezeigt, unabhängig davon ob die Tasks, welche die Informationen dafür zur Verfügung stellen, ausgeführt wurden oder nicht. Im letzteren Fall wurde also ggf. ein leerer Abschnitt in der Build Zusammenfassung angezeigt.
TFS 2018 stellt nun die neue Methode setSectionVisibility (vgl. Snippet 2) zur Verfügung. Diese kann im Quellcode einer Extension, welche den Abschnitt der Build Zusammenfassung definiert, verwendet werden um situationsabhängig die gewünschten Informationen und Abschnitte ein- und auszublenden. Für ein vollständiges Beispiel sei an dieser Stelle ebenfalls auf GitHub verwiesen.
VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", true);
Snippet 2: Einblenden von Custom Build Summary Sections
Release
Tasks in Release Definitionen können in verschiedenartigen Phasen ausgeführt werden. Eine Ausprägung davon ist die sogenannte Agentless Phase. Diese benötigt weder einen Agenten noch sonstige Zielmaschinen. Für Tasks, welche in solch einer Agentless Phase ausgeführt werden, sogenannte server-seitige Tasks, bringt TFS 2018 zwei Neuerungen:
Der neue Task Invoke REST API erlaubt es einen HTTP REST API-Aufruf aus dem Release heraus auszuführen (vgl. Abbildung 1). Hierzu ist es notwendig, im Vorhinein einen Generic Endpoint zu definieren, gegen welchen der Aufruf dann ausgeführt wird.
Der neue Task findet beispielsweise in folgendem Szenario Verwendung: Ein externer Dienst generiert anhand der ID eines Releases die zugehörigen Release Notes auf Basis der enthaltenen Work Items. Dieser Dienst kann mittels des Invoke Rest API-Tasks aus dem Release heraus ausgerufen werden und bis zur Fertigstellung der Release Notes gewartet werden.
Abbildung 1: Neuer server-seitiger Task Invoke REST API
Die zweite Neuerung bringt den Konfigurationsabschnitt Control Options nun auch für server-seitige Tasks. Die bereits bekannten Optionen Enabled, Continue on error, Always run sowie die Definition eines Timeouts steht damit nun auch für Tasks in Agentless Phasen zur Verfügung (vgl. Abbildung 2) und ermöglichen somit auch hier eine genauere Steuerung der Ausführung.
Abbildung 2: Control options
Build und Release
Eine Neuerung, welche sich sowohl im Build- als auch Releasemanagement wiederfindet, ist die Möglichkeit eigene Build Tasks als veraltet (Deprecated) zu kennzeichnen. Um Nutzern den Umstieg auf neuere Task-Versionen zu erleichtern, ist es empfehlenswert einen entsprechenden Hinweis in der Beschreibung der Tasks zu vermerken.
Um einen eigenen Task als veraltet zu markieren, muss das entsprechende Attribut in der Task Definition gesetzt werden:
"deprecated": true
Alle Deprecated Tasks werden im Task Katalog am Ende der Liste in einem eigenen Abschnitt Deprecated tasks zusammengefasst. Sowohl im Task Katalog als auch in Build- und Releasedefinition werden die Tasks zusätzlich als Deprecated gekennzeichnet (vgl. Abbildung 3).
Fazit
Auch im Bereich der Erweiterungen zeigt sich wieder einmal: das „neue alte“ Build- und Releasesystem wird erwachsen! Mit der Verteilung von eigenen Build Templates über VSTS- / TFS-Erweiterungen, der Möglichkeit eigene Tasks als veraltet zu markieren etc. geht Microsoft weitere Schritte um den Nutzern und Entwicklern von Erweiterungen das Leben leichter zu machen.
Bleiben Sie dran und begleiten Sie uns auch weiter bei der Entdeckung spannender Neuigkeiten in TFS 2018 in den Folgebeiträgen unserer Blogserie.