In einem vorigen Blog-Artikel hatte ich das neue Build-System vorgestellt. Auch in jenem Standard-Szenario eines Builds einer .NET-Solution bietet das neue Build-System einige Verbesserungen. Im heutigen Artikel möchte ich nun auf einen weiteren großen Vorteil eingehen: Builds für verschiedene Technologien – nicht nur aus der Microsoft-Welt. Anhand einer Build-Definition für eine Node.js-App zeige ich, dass das neue Build-System einfach und schnell erweitert und angepasst werden kann.
Da es für einen Node.js-Build keine Vorlage gibt, startet man am besten mit einer leeren Build-Definition. Wie im Bild oben zu sehen ist, gibt es schon einen Build-Schritt für die Ausführung von “npm install”, womit die Abhängigkeiten der Node.js-App aufgelöst und Pakete heruntergeladen werden. Danach werden Tests mit dem Framework Mocha.js ausgeführt, die Testergebnisse veröffentlicht, das Paket für die Veröffentlichung vorbereitet und anschließend wird dieses Paket auf dem Server als Build-Artefakt abgelegt.
Für den zweiten und vierten Schritt wird per “npm run <scriptname>” einfach ein Skript ausgeführt, welches schon im Paket enthalten ist. Da es sich beim Ausführen der Skripte um eine in npm schon integrierte Funktionalität handelt, klappt dies auf jeder Plattform. Leider gibt es für einen Aufruf von npm noch keinen eigenen Build-Schritt, daher wird hier ein PowerShell-Skript eingesetzt, welches einfach alle Argumente an npm weiterleitet:
1: Write-Output "Call npm with args: $args"
2: npm $args
Dies ist ein Paradebeispiel für einen neuen Build-Schritt, welchen man selbst anlegen werden kann. Damit ein Build-Schritt auf allen Plattformen funktioniert, kann ein Schritt aus mehreren Skripten bestehen, beispielsweise ein PowerShell-Skript für Windows und ein Bash-Skript für Unix-Systeme. Da man allerdings bisher keine eigenen Build-Schritte anlegen kann, wurde hier direkt ein PowerShell-Skript benutzt, womit der Build natürlich nur auf einem Windows-Agent ausgeführt werden kann.
Mit dem Mocha-Framework werden JavaScript-Tests ausgeführt und die Ergebnisse können in eine XML-Datei im xUnit-Format geschrieben werden. Ein Fehlschlagen dieses Schrittes kann nun zwei Dinge bedeuten: Entweder hat der Schritt selbst nicht funktioniert, z.B. da eine Datei nicht gefunden wurde und damit auch keine XML-Datei für die Testergebnisse erzeugt werden konnte, wodurch beim Veröffentlichen der Testergebnisse auch ein Fehler auftauchen wird. Oder mindestens ein Test schlug fehl, die XML-Datei wurde normal generiert, doch der Testrunner (in diesem Fall das Mocha-Framework) beendete den Prozess mit einem Exit-Code ungleich 0, was dem TFS mitteilt, dass der Build-Schritt fehlgeschlagen ist. Falls Testergebnisse erzeugt wurden, können diese mit dem Build-Schritt “Publish Test Results” direkt veröffentlicht werden. Die Formate der nUnit-Familie sind weit verbreitet und werden vom TFS unterstützt.
In den letzten beiden Schritten wird das npm-Paket geschnürt, indem nur die relevanten Dateien in einen Ausgabeordner kopiert werden und diese dann als zip-Datei im Server abgelegt werden. Natürlich wäre es auch möglich, das npm-Paket direkt in der öffentlichen npm-Registry zu veröffentlichen, was in einem weiteren Build-Schritt mit einem Skript geregelt werden kann.
Alle im Build genutzten Technologien müssen natürlich auch auf dem Build-Agent zur Verfügung stehen. Im Reiter “General” werden sie explizit als “Demand” gelistet:
Manche Demands werden automatisch hinzugefügt basierend auf den eingesetzten Build-Schritten. Zum Beispiel wurde durch den Schritt “npm install” der Demand “npm” und durch den Schritt “PowerShell” der Demand “DotNetFramework” hinzugefügt. Diese können nur gelöscht werden, indem die Build-Schritte entfernt werden. Andere Demands können händisch eingefügt werden, z.B. “node”, da Node.js zum Ausführen der Mocha-Test notwendig ist. Das Gegenstück zu den Demands sind “Capabilities” des Build-Agents, die meisten werden wieder automatisch ermittelt. Ein Build kann natürlich nur auf einem Agent ausgeführt werden, der alle Demands erfüllt. Dies ersetzt die Tags im alten Build-System und bietet eine deutlich übersichtlichere und einfachere Verwaltung.
Gerade Node.js Apps werden häufig auf GitHub gehostet. Mit dem neuen Build-System ist dies kein Problem, denn es unterstützt nun auch eine Anbindung an GitHub oder anderen externen Git Repositories:
Damit öffnet sich Microsoft noch stärker der Open-Source-Community und ermöglicht die Nutzung des TFS in den unterschiedlichsten Projekten.
Fazit:
Mit dem neuen Build-System können Build-Definitionen für praktisch alle Technologien für Windows, Mac OSX und Linux erstellt und ausgeführt werden – vorausgesetzt man kann den Vorgang über ein Skript steuern – egal ob das Projekt einen Compiler für C#, C++, Objective-C benötigt oder gar keinen, da es simpler JavaScript-Code ist. Open-Source-Projekte in Git Repositories können ebenfalls genutzt werden, wodurch nun mehr Projekttypen den TFS bzw. VSO nutzen können.
Falls es nicht schon einen vorgefertigten Build-Schritt gibt, kann einfach ein Skript genutzt werden. Für generische Aufgaben wird die Erstellung eines eigenen Build-Schrittes möglich sein. Diese Anpassungsmöglichkeiten sind – vor allem im Vergleich zu den alten XAML-Definitionen – sehr flexibel und simpel umzusetzen. Das Erlernen einer eigenen Sprache, wie sie in den XAML-Definitionen angewendet wurde, ist nicht mehr notwendig.