Seite 4: Build für Angular

Inhaltsverzeichnis

Beim Erstellen des Build-Prozesses für den HTML- und Angular-basierten Cross-Platform-Client lässt sich nicht auf eine Vorlage wie bei dem ASP.NET-Core-Build zurückgreifen. Hier erstellt man eine Build-Pipeline komplett aus einzelnen Schritten mit vordefinierten Tasks. Microsoft stellt ein paar Dutzend solcher Tasks im Standard in der Weboberfläche bereit, und auf dem Azure DevOps Marketplace gibt es über 550 Erweiterungen für Azure Pipelines. Es ist dokumentiert, wie man eigene Erweiterungen für Azure DevOps mit PowerShell oder Node.js schreibt. Mit dem Pluszeichen (s. Abb. 5) ergänzt man Tasks, deren Reihenfolge man per Drag & Drop jederzeit ändern kann. Einzelne oder mehrere markierte Schritte kann man per Kontextmenü deaktivieren, klonen oder löschen.

Die Build-Pipeline für den "Miracle List"-Client besteht aus acht Schritten:

1. Mit einem "Node Tools Installer" wird Node.js 8.x installiert. Die Version wird in der Eigenschaft "Version Spec" erfasst.
2. Dann wird mit einem "npm"-Task die Angular CLI installiert. Man wählt als "Command" den Eintrag "custom" und als Argument "install -g @angular/cli@1.5.0".
3. Danach folgt mit der gleichen Task-Art und dem Befehl "install" das Herunterladen aller benötigten npm-Pakete von www.npmjs.org.
4. Ein dritter "npm"-Task startet dann die Unit-Tests (Befehlsart: "custom", Argument: "run test-headless").
5. Nun folgt ein Task mit dem Namen "Publish Test Results". Dieser sorgt dafür, dass die Testergebnisse, die im vorherigen Schritt im JUnit-Format in der Datei unitests.xml persistiert wurden, nun in Azure DevOps für die Testergebnisanzeige importiert werden – sonst weiß Azure DevOps nicht, ob die Tests erfolgreich waren.
6. Im sechsten Schritt erfolgt nun der Produktions-Build der Angular-Anwendung. Hierzu wird ein Task des Typs "Command Line" verwendet. Dabei ist bei "Tools" der Wert "ng" und bei "Arguments" der Wert "build --prod" einzutragen.
7. Das Angular-Kommandozeilenwerkzeug ng erzeugt ein Ausgabeverzeichnis "/Dist". In Azure DevOps ist aber die Weitergabe als Zip-Datei üblich. Daher folgt ein Task des Typs "Archive Files", bei dem als " Root folder or file to archive" der Wert "dist" erfasst wird und als Ausgabedatei folgender Pfad mit vordefinierten Azrue DevOps-Variablen: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip. Das Archiv erhält damit bei jedem Durchlauf einen eindeutigen Namen, da sich die Build-ID ändert.
8. Nun kommt im letzten Schritt die Bereitstellung der Zip-Datei für die Folge-Pipelines, die es auch schon bei der Build-Pipeline für den Server gab (s. Abb. 1).

Fazit

Sowohl der ASP.NET-basierte Server als auch der Angular-Client werden nun serverseitig bei jedem Code-Check-in automatisch übersetzt und getestet. Aber die Tests sind noch nicht vollständig, denn es wurde noch nicht die Weboberfläche, die Web-API und das Zusammenspiel mit einer echten Datenbank getestet. Im dritten Teil dieser Serie geht es dann um diese Integrations- und UI-Tests sowie das vollautomatische Ausliefern der Software im Sinne von Continuous Delivery, wenn die Tests erfolgreich waren.

Dr. Holger Schwichtenberg
leitet das Expertennetzwerk www.IT-Visions.de, das Beratung, Schulungen und Softwareentwicklung im Umfeld von Microsoft-, Java- und Web-Techniken anbietet. Er selbst schreibt Software in C# und JavaScript/TypeScript, hält Vorträge auf Fachkonferenzen und ist Autor zahlreicher Fachbücher. (ane)