Automatisierte Tests, Builds & Deployments für React mit VSTS

Einführung

Ein großer Vorteil bei der Nutzung von Visual Studio Team Services (VSTS) ist die kontinuierliche Integration und Bereitstellung.

 
Dunkelblauer Hintergrund mit hellblauem React und Visual Studio Team Symbolen

 

So beschreibt Microsoft diese Funktion:

Erfassen Sie Qualitätsprobleme früher mithilfe von Build-Definitionen, die Ihre Anwendungen automatisch in der Cloud kompilieren und testen, entweder nach Bedarf oder nach jeder Änderung am Code. Verfolgen Sie die Buildintegrität im Lauf der Zeit mit Diagrammen und anpassbaren Dashboards. Nach erfolgreichem Durchlaufen der Tests werden Ihre aktualisierten Websites automatisch direkt in Azure bereitgestellt.

Im folgenden Artikel möchte ich ein neues Projekt für die Verwendung von CI/CD einrichten. Dabei wird in zwei Phasen unterteilt: Build & Release.

Nach der erfolgreichen Einrichtung der Basisfunktionen (Projekt Setup und Deployments auf die Hosting Umgebung — Azure) werden wir die Build Definition noch erweitern, so dass auch die Tests für das Projekt automatisch ausgeführt werden.

 

Grundlegende CI / CD Konfiguration für das Projekt erstellen

1. Build: Kompilierung des Quellcodes

Innerhalb von VSTS wählen wir den Tab Build und erstellen uns eine neue Definition:

 

Eine neue Build Definition erstellen

 

Um die einzelnen Schritte besser zu verstehen, wählen wir die Option Empty process (die existierenden Templates sind zum Zeitpunkt des Artikels auch nicht wirklich hilfreich).

 

Process

Hier geben wir unserer Definition einen Namen und wählen die Agenten-Warteschlange aus:

Um ein React Projekt zu erstellen müssen wir hierbei keine spezielle Auswahl treffen, da alle Agents die Vorraussetzungen erfüllen. Wir wählen also bspw: Hosted — Standard : Hosted.

Die Nutzung der Hosted Agents ist auch in der kostenlosen Testversion von VSTS direkt nutzbar.

Dadurch werden alle folgenden Schritte auf den öffentlichen Build-agents von Microsoft durchgeführt. Es ist auch möglich eigene Rechner als Build Agent zu konfigurieren.

 

Get Sources

Hier wählen wir unser Projekt innerhalb VSTS oder aus einem externen Repository (GitHub, etc.) aus. Bei der Auswahl des Branches wählen wir den Branch develop, da unsere Build-Definition für Testumgebungen gedacht ist.

 

Phase 1

Erst hier werden die benutzerdefinierten Schritte für den Build Prozess definiert.

Wir definieren die folgenden Tasks:

  1. Installieren der benötigten NPM Pakete

  2. Exportieren / Erstellen : Build

  3. Archivieren

  4. Publish Build Artifacts

 

1. NPM install

Wir fügen uns einen neuen Build Schritt hinzu:

 

Einen neuen Build Schritt hinzufügen

 

Die Standardkonfiguration füllt direkt alle benötigten Felder passend aus. Falls die Datei package.json nicht im Stammverzeichnis des Repositories liegt, so gibt man unter Working folder noch die Verzeichnisstruktur an.

 

2. NPM build

Wir fügen noch einen NPM-Build Schritt hinzu und konfigurieren ihn für unser Build oder Export Skript:

 

NPM Build Schritt hinzufügen

 

3. Archive zip

Dieser Schritt ist optional, aber durch das packen des gesamten Build Outputs aus dem vorherigen Schritt ist es deutlich kompakter und wir erhalten eine einzelne Datei von unserem Build.

Hier müssen auch nur diese Einträge gemacht werden:

Root folder to archive : Ausgabeordner aus dem Build/Export Skript, bspw. dist/.

 

Archive file to create :

$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip

Durch diese Einstellungen wird das komprimierte Archiv später als Build Artefakt für den Release Schritt zur Verfügung gestellt.

 

4. Publish Build Artifacts

 

Continuous Integration für automatisierte Builds bei Push auf Bestimmten branch aktivieren

 

Nachdem nun unser Build Prozess abgebildet ist können wir nun noch unter dem Tab Triggers die Option Continuous Integration aktivieren, die für jeden Push auf einen bestimmten Branch (develop) einen Build auslöst.

 

2. Release : Upload auf den Server

Nachdem wir also nun unser Build-Artefakt als .zip exportiert haben können wir eine Release-Definition erstellen:

Wir können dieses Mal eine Vorlage nutzen Azure App Service Deploy

 

Vorlage Azure App Service Deploy als Release Definition

 

Nach dem laden der Vorlage landen wir auf der Pipeline Ansicht.

Jetzt fehlen uns nur noch wenige Schritte:

  1. Verknüpfen der Build Artefakte

  2. Konfigurieren des Environments

 

1. Verknüpfen der Build Artefakte

 

Kontinuierliches Erstellen des Releases durch Blitz Icon aktivieren

 

Nach dem die Build Artefakte verknüpft sind, kann man durch Anwählen des Blitz Icons auch noch den Trigger fürs kontinuierliche Erstellen des Releases aktivieren.

 

2. Konfiguration Environment

 

Release Staging
Build und Release Definition

 

Geschafft !

Wir haben unser neues Projekt mit VSTS erfolgreich für CI/CD konfiguriert.

In der aktuellen Einstellung wird das Projekt bei jedem neuen Push auf dem Zweig develop erneut durch unsere Build & Release Definition geschickt.

Erweiterung: Tests innerhalb des Projektes ausführen

Für die folgenden Schritte wird von einem Projekt ausgegangen, welches bereits die grundsätzlichen Pakete für Mocha/Jest installiert hat.

Für diese Erweiterung führen wir die folgenden vier Schritte aus:

  1. Vorbereitung im Projekt : Package anpassen

  2. Build Prozess anpassen

  3. Test Results ansehen

  4. Deploy to Azure Webapp

 

1. Vorbereitungen im Projekt

Die Ausführung der Tests werden üblicherweise über ein npm-Skript definiert und können mit npm run test ausgeführt werden.

Im Ausgangszustand werden die Ergebnisse der Tests von bspw. Mocha aber nur in der Konsole ausgegeben und sind in keinem passenden Format für Visual Studio Team Services.

Wir fügen ein neues Script in unserer package.json hinzu:

 

scripts: {
[...]
"test-vsts": "mocha --reporter mocha-junit-reporter
--reporter-options mochaFile=./test-output/test-results.xml"
}

 

In dieser Zeile sind vor allem die Variablen reporter mocha-junit-reporter und die dazugehörigen reporter-options von Bedeutung.

Durch die Wahl des Reporters können wir unsere Testergebnisse in ein für VSTS kompatibles Format konvertieren (JUNIT). Außerdem bestimmen wir direkt noch das Ausgabeverzeichnis für unsere Ergebnisse.

Hinweis:

Damit das Skript korrekt ausgeführt werden kann müssen wir aber vorher noch die genutzten Pakete installieren:

 

npm i -D mocha-junit-reporter

 

Den VSTS Build Prozess anpassen

Nachdem wir nun die Vorbereitungen abgeschlossen haben bewegen wir uns wieder in den VSTS Build & Release Bereich. Dort wählen wir Edit Build Definition

Nun wollen wir unserem Build Prozess zwei weitere Schritte hinzufügen:

  1. Tests durchführen
  2. Testergebnisse exportieren

 

1. Tests durchführen

Im vorherigen Schritt haben wir uns ein weiteres Skript für NPM erstellt welches wir nun in den Build Prozess integrieren können:

 

NPM Skript Integration in Build Prozess

 

Nun müssen wir nur noch das passende Skript ausführen in dem wir im Bereich Command die Option custom festlegen. Danach tragen wir unter command and arguments folgenden Text eingeben: run test-vsts. (Nicht mit dem Skript test verwechseln, da dieses nicht den gewünschten Reporter konfiguriert hat).

 

2. Testergebnisse exportieren

In unserer Datei package.json haben wir zusätzlich noch den Pfad für die Ausgabedatei definiert. Nun müssen wir nur noch diese Datei als Testergebnisse für VSTS exportieren.

Wir fügen einen neuen Build Task hinzu:

 

Hinzufügen der Export Task für Testergebnisse

 

Und konfigurieren den Task mit den vorher eingestellten Optionen (JUNIT ist nur ein Beispiel, welches VSTS unterstützt )

 

Export Task konfigurieren

 

Fertig!


 

Nun können wir uns bei jedem Build die Testergebnisse für unser Frontend in VSTS direkt ansehen und fehlgeschlagene Tests führen zu keinen Builds (Außer man aktiviert die Funktion continue on error für den Test-Task).

 

Testergebnis in VSTS anzeigen
Erfolgreicher automatisierter Build

 


 

Ein weiterer Artikel zum Thema CI/CD ist schon geplant und in diesem erfahrt ihr, wie ihr ein System ähnlich wie Netlify aufbaut. Dabei werden für jeden neuen Branch jeweils einzelne, unabhängige App Service erstellt und nach einer manuellen Testphase & Freigabe automatisch wieder vom System entfernt. Dadurch erreicht ihr eine sehr hohe Qualität und könnt das System ideal in euren bestehenden Review-Prozess einbauen.

 

 

Ähnliche Artikel

Developer Content
12. Oktober 2023 4 Min. Lesezeit
Das Rad nicht neu erfinden - IT Frameworks einsetzen lohnt sich
Weiterlesen
Developer Content
26. Januar 2022 4 Min. Lesezeit
Was Kuchenbacken und Softwareentwicklung gemeinsam haben
Weiterlesen
Developer Content
14. August 2020 6 Min. Lesezeit
Einstieg in die testgetriebene Entwicklung
Weiterlesen
Developer Content
1. April 2020 7 Min. Lesezeit
Code Review bei BRICKMAKERS
Weiterlesen
Developer Content
6. März 2020 2 Min. Lesezeit
Kovarianz und Kontravarianz von Unit-Tests
Weiterlesen
Developer Content
11. Dezember 2019 3 Min. Lesezeit
Cloud Architekturen im Überblick
Weiterlesen
Pfeil nach links
Pfeil nach rechts