CI/CD Pipeline

Ein wichtiger Schwerpunkt dieser Entwicklungsphase war der Aufbau einer zuverlässigen und möglichst automatisierten CI/CD-Infrastruktur. Ziel war es, den gesamten Deployment-Prozess zu vereinfachen, Fehlerquellen zu reduzieren und neue Versionen mit möglichst geringem manuellen Aufwand bereitzustellen.

Architektur

Als zentrale Quelle für den gesamten Quellcode dient GitHub. Alle relevanten Repositories werden dort verwaltet und versioniert. GitHub fungiert dabei als „Single Source of Trut“, sodass jederzeit nachvollziehbar ist, welcher Code aktuell produktiv eingesetzt werden soll.

Sobald neuer Code in eines der Frontend-Repositories gepusht wird, löst GitHub automatisch einen Webhook aus. Dieser Webhook wird von einem selbst entwickelten FastAPI-Service auf unserem Server empfangen.

Der Webhook-Service übernimmt dabei die Aufgabe, Deployments kontrolliert und automatisiert anzustoßen. Für jeden Container existiert ein eigenes Deployment-Skript sowie ein eigener API-Endpunkt. Wird ein Endpunkt mit dem korrekten API-Schlüssel aufgerufen, startet der entsprechende Deployment-Prozess.

Der Ablauf sieht dabei wie folgt aus:

1. GitHub sendet einen Webhook an den Server.
2. Der FastAPI-Service validiert die Anfrage.
3. Das zugehörige Deployment-Skript wird ausgeführt.
4. Der aktuellste Quellcode wird aus dem Repository geladen.
5. Ein neues Docker-Image wird erstellt.
6. Der bestehende Container wird durch die neue Version ersetzt.

Dadurch werden neue Frontend-Versionen nach einem erfolgreichen Push automatisch bereitgestellt.

Backend Deployment

Für das Backend verwenden wir einen leicht abgewandelten Workflow.

Da das Projekt langfristig möglichst einfach von anderen Personen selbst gehostet werden können soll, haben wir uns dafür entschieden, die Docker-Images zentral über GitHub Actions zu erstellen. Dadurch müssen spätere Nutzer das Backend nicht selbst kompilieren, sondern können direkt ein vorgefertigtes Image verwenden.

Aktuell wird die Build-Pipeline durch folgende Ereignisse ausgelöst:

• Erstellung eines neuen Releases
• Manueller Workflow-Start über GitHub Actions

Nach dem Start erstellt GitHub Actions automatisch ein neues Docker-Image des Backends. Das Image ist derzeit noch privat, soll jedoch zukünftig öffentlich verfügbar gemacht werden, sodass andere Nutzer es direkt verwenden können.

Sobald der Build-Prozess erfolgreich abgeschlossen wurde, wird erneut ein Endpunkt unseres FastAPI-Webhook-Services aufgerufen. Anders als beim Frontend muss hierbei kein Quellcode mehr heruntergeladen werden. Stattdessen wird lediglich das neu erzeugte Docker-Image bezogen und der bestehende Container neu erstellt.

Optimierungen

Während der Entwicklung der Deployment-Pipeline wurde besonderes Augenmerk auf die Effizienz der Docker-Images gelegt.

Für das Backend setzen wir deshalb auf einen Multi-Stage-Docker-Build. Dadurch werden Build-Abhängigkeiten von den tatsächlich benötigten Laufzeit-Abhängigkeiten getrennt. Nicht benötigte Dateien gelangen somit gar nicht erst in das finale Image.

Dies führte zu einer deutlichen Reduzierung der Image-Größe auf ungefähr ein Drittel der ursprünglichen Größe.

Kleinere Images bieten mehrere Vorteile:

• Schnellere Build-Zeiten
• Kürzere Download- und Deployment-Zeiten
• Geringerer Speicherverbrauch
• Reduzierte Angriffsfläche durch weniger enthaltene Komponenten

Vorteile des Ansatzes

Die entwickelte CI/CD-Pipeline bietet mehrere Vorteile:

• Vollständig nachvollziehbare Deployments
• Automatisierte Bereitstellung neuer Versionen
• Reduzierung manueller Fehler
• Einfache Wartbarkeit
• Gute Skalierbarkeit für zukünftige Erweiterungen
• Vereinfachtes Self-Hosting durch vorgefertigte Docker-Images

Durch diese Architektur können neue Versionen innerhalb weniger Minuten automatisiert gebaut und bereitgestellt werden, während gleichzeitig eine klare Trennung zwischen Quellcode, Build-Prozess und Produktivsystem gewährleistet bleibt.