Praktikum IV

Project ID: 1220

Motivation

Dieses Praktikum dient der Vertiefung im Umgang mit CI/CD-Pipelines (hier: GitLab-CI/CD). Dies ist wichtig, um die zu entwickelnde Anwendung stetig zu bauen und möglichst schnell Ergebnisse und Fehler zu erkennen. Da der Deployment-Prozess auch heute noch erfahrungsgemäß eine große Fehlerquelle des Softwareentwicklungsprozesses birgt, sollte dieser möglichst früh angegangen und durchgeführt werden, auch wenn natürlicherweise noch Fehler entstehen. Das Prinzip ist hier: Fail fast. Learn fast.

Außerdem soll zu Unterstützung testgetriebener Entwicklung (zuerst die Tests programmieren, danach das eigentlich Programm) eine Pipeline aufgebaut werden, welche diesen Ablauf grundsätzlich ermöglicht.

Vorbereitung

Für die Vorbereitung des Praktikumsversuchs wird mit einem Selbststudienaufwand von 12 Zeitstunden kalkuliert.

Test Driven Development (TDD)
- What is Test Driven Development?
- Test-driven development: by example

Ausgangspunkt

Sie erhalten einen Laborrechner mit einem frisch installierten Ubuntu-Betriebssystem. Installieren Sie die erforderlichen Werkzeuge, die Sie aus dem letzten Praktikum kennen, bei Bedarf nach.

Durchführung

Im Folgenden werden die Arbeitsschritte beschrieben, die Sie durchführen müssen, um das Praktikum erfolgreich zu absolvieren. Hinweise sind anhand der kursiven Schrift zu erkennen.

Erstellen Sie im Wiki des zuvor erstellten GitLab-Projekts ein Laborprotokoll. Notieren Sie hier strukturiert Ihre Arbeitschritte mit kopier- und ausführbaren Kommandozeilenbefehlen in dieser Form:

docker run hello-world

Das Laborprotokoll soll dem Laborpersonal am Ende gemeinsam mit der kurzen Vorführung der Ergebnisse gezeigt werden.

Mittlerweile sollten Sie sicher im Umgang mit dem Terminal und Gitlab-Runner sein.

Schritt 1

In Hinblick auf das anstehende fünfte Praktikum nutzen wir das offizielle gitlab.com GitLab für die Bearbeitung des folgenden Projekts. Erstellen Sie bitte - falls noch nicht vorhanden - einen eigenen Account.

Arbeiten Sie die folgenden Schritte ab:

Rufen Sie die Seite zum Import eines Projekts auf: https://gitlab.com/projects/new#import_project
Wählen Sie Repository by URL aus
Tragen Sie folgende URL in das Feld Git repository URL ein: https://gitlab.hsrw.eu/lv-swe/praktika/praktikum-iv-vorlage.git
Setzen Sie kein Häkchen bei Mirror repository
Da das zu importierende Projekt nicht öffentlich ist, müssen Sie Ihre Zugangsdaten zum Hochschul-GitLab angeben
Vergeben Sie einen geeigneten Namen und Ihre gewünschte Projektsichtbarkeit
Erstellen Sie das Projekt durch den Button Create project

Alle weiteren Schritte erarbeiten Sie bitte in Ihrem persönlichen Projekt. Denken Sie daran, dass Sie den GitLab-Flow aus dem letzten Praktikum benutzen sollen, um die Arbeitsweise zu verinnerlichen.

Schritt 2

Unter /src/app/sum/sum.router.ts finden Sie eine unvollständige TypeScript-Datei vor. Wir wollen in diesem Praktikum testgetrieben mit Hilfe einer Gitlab-Pipeline die Lösung erarbeiten. Die Tests wurden bereits unter /src/app/sum/sum.test.ts erstellt, hier müssen Sie keine weiteren Änderungen vornehmen.

Im Hauptverzeichnis finden Sie bereits eine rudimentäre .gitlab-ci.yml vor. Sie werden diese in den folgenden Schritten nach und nach ergänzen, bis die Pipeline vervollständigt wurde. Registrieren Sie zunächst wieder einen Runner für Ihr Projekt und überprüfen Sie die grundsätzliche Funktionalität. Deaktivieren Sie in den CI/CD Settings Ihres Projekts zusätzlich die Shared runners. Deaktivieren Sie dazu die Option Enable shared runners for this project.

Schritt 3

Bevor wir den Code in sum.router.ts ergänzen, wollen wir noch sicherstellen, dass er stets korrekt formatiert wird. Dies soll in der Stage lint realisiert werden. Die eigentliche Formatierung wird von Prettier übernommen.

Erweitern Sie die Stage um die folgenden Punkte:

Installieren Sie alle benötigten Pakete. In diesem Projekt wird npm als Paketmanager genutzt. Sie kennen aus den vorherigen Praktika bereits Yarn, die Funktionalität ist in den meisten Punkten vergleichbar.
Finden Sie heraus, wie Sie Prettier aufrufen können. Alle benötigten Informationen sind in der package.json enthalten.
Testen Sie Ihre Pipeline und schauen Sie sich die Ergebnisse an.

Schritt 4

Mit der aktuellen Pipeline wird der Code lediglich lokal beim Gitlab-Runner formatiert. Falls Änderungen vorgenommen wurden, soll allerdings sofort ein Commit ins Repository erfolgen.

Fügen Sie der Stage die folgenden Schritte hinzu:

Überprüfen Sie zunächst, ob überhaupt Änderungen durchgeführt wurden. Falls keine Änderungen vorgenommen wurden, sind die folgenden Schritte nicht durchzuführen. An dieser Stelle ist es sinnvoll sich mit Multiline Blocks zu befassen.
Erstellen Sie einen Commit mit einer geeigneten Commit-Nachricht. Überlegen Sie, ob die Option -a an dieser Stelle sinnvoll ist.
- Unter Umständen müssen Sie hier noch git konfigurieren und eine Mail-Adresse sowie den Benutzernamen setzen.
Pushen Sie die Änderungen auf den HEAD des aktuellen Branches.
- Hier werden Sie vermutlich Probleme bekommen, da Gitlab die Eingabe von Zugangsdaten erwartet. Um das Problem zu lösen, müssen die folgenden Schritte durchgeführt werden:
  - Erstellen Sie sich ein Access Token. Dies ist unter Settings -> Access Tokens möglich. Vergeben Sie einen geeigneten Namen für den resultierenden Bot und setzen Sie den Haken bei write_repository. Wählen Sie eine geeignete Rolle für das Token. Achtung: Sie müssen das Token kopieren, sobald die Seite verlassen wurde ist es für immer verloren!
  - Wechseln Sie nun zu Settings -> CI/CD -> Variables und fügen Sie eine Variable hinzu. Sie können diese z.B. PROJECT_ACCESS_TOKEN nennen, fügen Sie das kopierte Token als Value ein. Ist es sinnvoll die Variable zu schützen oder zu maskieren? Treffen Sie eine Entscheidung!
  - Erweitern Sie Ihren Push-Befehl gemäß dieser Anleitung.
Der erneute Commit wird die Pipeline erneut triggern. Ist das ein erwünschtes Verhalten? Begründen Sie Ihre Antwort!
Schicken Sie einen Exit-Code, der die Pipeline als fehlerhaft beendet.

Sollten Sie Inspiration benötigen, ist u.a. dieser Blog-Post interessant.

Testen Sie abschließend Ihre Änderungen!

Schritt 5

Jetzt muss die Stage test erweitert werden. In diesem Fall sind die folgenden Schritte durchzuführen:

Führen Sie die Tests aus. Auch hier finden Sie alle benötigten Informationen in der package.json. Setzen Sie sich darüber hinaus mit npm clean-install auseinander und entscheiden Sie, ob eine Verwendung hier angebracht ist.
Im Zuge der Tests erhalten wir zusätzlich zu den Tests einen Code-Coverage-Bericht. Dieser soll in das Gitlab-Projekt eingebunden werden. Benutzen Sie die folgenden Quellen: Gitlab Doku & Gitlab Forum
Unter Settings -> CI/CD -> General pipelines finden Sie den Coverage Report und den Pipeline Status. Binden Sie diesen in das Readme des Projekts ein.

Testen Sie auch hier wieder die erweiterte Funktionalität!

Schritt 6

Jetzt haben Sie die Grundlage für die testgetriebene Entwicklung geschaffen. Vervollständigen Sie sum.router.ts und überprüfen Sie mit Hilfe der Pipeline Ihren Fortschritt.

Abtestat

Demonstrieren Sie dem Laborpersonal Ihre vollständige Gitlab-Pipeline. Seien Sie bereit, auf Fragen des Laborpersonals ausführlich antworten zu können.

◀ Zurück zur Veranstaltung

Version

v2023b getestet am 16.05.2023