Praktikum V

Project ID: 1221

Motivation

Dieses Praktikum dient der Vertiefung im Umgang mit CI/CD-Pipelines (hier: GitLab-CI/CD) und dem abschließenden Deployment auf eine Produktivumgebung (hier: Render). 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.

Vorbereitung

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

Informieren Sie sich über Render:
- Dokumentation

Ausgangspunkt

Sie haben Praktikum IV erfolgreich fertiggestellt. Dieses Praktikum baut unmittelbar darauf auf und wird im gleichen Projekt weiterentwickelt. Sollten Sie noch nicht mit Praktikum IV fertig sein, beenden Sie dieses zunächst!

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:

sudo gitlab-runner register

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

Erweitern Sie Ihre .gitlab-ci.yml um eine weitere Stage commitChanges:

stages:
  - lint
  - test
  - commitChanges

...

Ergänzen Sie am Ende Ihrer .gitlab-ci.yml zunächst den folgenden Platzhalter:

...

Merge manually into production:
  stage: commitChanges
  script:
    - echo "Hier muss noch etwas erledigt werden :)"

In der neuen Stage commitChanges soll auf Wunsch ein manueller Merge in einen Branch mit dem Namen production erfolgen. Diese Stage muss für eine erfolgreiche Pipeline erfolgreich durchlaufen. Führen Sie die folgenden Schritte durch:

Führen Sie in der Stage einen Checkout auf den Remote-Branch Production aus.
Führen Sie einen Merge des aktuellen Branches in den Remote Production Branch durch.
Setzen Sie einen geeigneten Tag bestehend aus Major, Minor und Patch Nummer (z.B. v1.1.1). Nutzen Sie dafür in der .gitlab-ci.yml Variablen. Setzen Sie die Default-Werte jeweils auf '0'. Fügen Sie in Ihrer .gitlab-ci.yml den folgenden Abschnitt ein und ergänzen Sie diesen entsprechend:

stages:

...

variables:
  MAJOR:
    # Hier muss etwas erledigt werden
  MINOR:
    # Hier muss etwas erledigt werden
  PATCH:
    # Hier muss etwas erledigt werden

Fix linting errors:

...

Abschließend müssen sowohl der Tag als auch die Änderungen am Production Branch in das Repository gepusht werden. Beachten Sie wieder die Hinweise aus Schritt 4 des letzten Praktikums. Achtung: Durch die Änderungen wird die Pipeline abermals getriggert und Sie erzeugen eine Endlosschleife. Ergänzen Sie den Push-Befehl durch geeignete Optionen.

Beachten Sie, dass diese Stage selbstverständlich nicht auf dem Branch production laufen soll.

Testen Sie auch hier wieder die erweiterte Funktionalität!

Sobald Sie den manuellen Merge-Job ausführen, können Sie die Werte in den Eingabefeldern für die Variablen entsprechend setzen:

Bitte beachten Sie, dass bei Nutzung der Default-Werte (v0.0.0) ein Fehler auftritt, sobald dieser Tag einmal existiert:

Unter Repository -> Tags können Sie ihre versionierten Tags einsehen:

Hinweis: Gegebenenfalls müssen Sie eine Änderungen am Klonverhalten der Pipeline durchführen. Zuletzt konnte der Schritt aber auch erfolgreich ohne diese Änderung durchgeführt werden. Sie müssen an dieser Stelle nicht im Detail nachvollziehen können, weshalb das notwendig ist. Grundsätzlich handelt es sich hier um ein Problem mit dem shallow cloning. Gehen Sie zu Settings -> CI/CD -> General pipelines und setzen Sie den Wert unter Git shallow clone auf 0.

Schritt 2

Erstellen Sie sich einen Render-Account. Sollten Sie in der Vergangenheit bereits einen erstellt haben, können Sie selbstverständlich auch diesen nutzen. Alternativ können Sie sich auch mit Ihrem gitlab.com Account einloggen.

Schritt 3

Erstellen Sie nach der erfolgten Registrierung und anschließendem Login einen neuen Web Service auf Render unter New -> Web Service.

Verbinden Sie jetzt Ihren gitlab.com Account mit Render:

Anschließend erlauben Sie den Zugriff auf Ihren Account:

Verbinden Sie Ihr GitLab-Repository, das Ihre Summenberechnung aus dem letzten Praktikum bereitstellt:

Geben Sie Ihrem Service einen geeigneten Namen und wählen Sie als Region Frankfurt (EU Central) aus. Da wir unsere Produktivseite bereitstellen möchten, sollte der Branch production gewählt werden. Darüber hinaus treffen Sie Entscheidungen für die folgenden Parameter:

Runtime
Build Command
- Welcher Befehl soll zum Bauen der Anwendung ausgeführt werden?
Start Command
- Wie starten Sie Ihren Web Service?

Testen Sie die Befehle am besten lokal in Ihrem geklonten Projekt auf Ihrem Arbeitsgerät und erstellen Sie erst dann den Service auf Render.

Schritt 4

Jetzt können Sie mit weiteren Arbeiten in Ihrer .gitlab-ci.yml beginnen. Führen Sie die folgenden Schritte durch:

Fügen Sie eine weitere Stage deploy hinzu. Diese soll ausschließlich auf dem Branch production ausgeführt werden.
Änderungen an der Webseite sollen nicht automatisch von Render erkannt werden. Schalten Sie in den Settings des Web Services den Auto-Deploy aus. Die Änderung soll über die Render Deploy Hook aus der .gitlab-ci.yml an Render weitergeleitet werden. Sie finden die Deploy Hook in den Settings Ihres Web Services auf Render. Achtung: behandeln Sie den Key in der Hook wie ein Passwort! Nutzen Sie am besten eine maskierte Variable für den Key. Schauen Sie sich auch den folgenden Foreneintrag an: Forum
Erstellen Sie das zugehörige Environment, damit dieses in Ihrem Gitlab-Projekt unter Deployments -> Environments hinzugefügt wird.

Schritt 5

Testen Sie Ihr Deployment und rufen Sie verschiedene Summenberechnungen auf. Gerne können Sie die Zahlen aus der Testklasse nutzen.

Schritt 6

Zum Abschluss des Praktikums wird es die Möglichkeit geben noch einmal über sämtliche Themen zu sprechen. Bereiten Sie im Hinblick auf die anstehende Prüfung Fragen vor.

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

v2023a getestet am 16.05.2023