Abstract

Die vorliegende Semesterarbeit befasst sich mit der automatisierten Bereitstellung von kurzlebigen (ephemeren) Testumgebungen in der Amazon Web Services (AWS) Cloud. Für jeden Merge Request (MR) in GitLab soll automatisch eine eigene, isolierte Umgebung entstehen, die bei jedem neuen Commit aktualisiert und beim Merge oder Schliessen des MR wieder abgebaut wird.

Problematik

Änderungen an einer Webanwendung werden heute meist erst nach dem Merge auf einer gemeinsamen Testumgebung sichtbar. Laufen mehrere Merge Requests parallel, überschreiben sie sich dort gegenseitig, Reviewer können eine Änderung nicht isoliert ausprobieren und Fehler fallen zu spät auf. Von Hand erstellte Test-VMs werden zudem gerne vergessen und verursachen laufende Kosten.

Zielsetzung und Methodik

Ziel dieser Arbeit ist eine Lösung, welche pro Merge Request vollautomatisch eine eigene Review-Umgebung auf AWS bereitstellt, aktualisiert und wieder abbaut. Methodisch wird hierbei bewusst eine entkoppelte Architektur umgesetzt: Die GitLab-Pipeline legt nur einen Auftrag in eine SQS-FIFO-Queue, eine Lambda-Funktion (Python) setzt diesen um. Die langlebige Basis-Infrastruktur wird vollständig in Terraform beschrieben und über die Pipeline ausgerollt. Als Oberfläche dienen die bestehenden GitLab «Review Apps» (Environment, URL, Stop-Auslöser).

Ergebnisse

Durch die technische Umsetzung erhält jeder Reviewer eine eigene, isolierte Umgebung, deren URL direkt im Merge Request sichtbar ist. Parallele Merge Requests stören sich nicht mehr gegenseitig, und da jede Umgebung beim Merge oder Schliessen automatisch abgebaut wird, entstehen keine vergessenen Instanzen und damit keine unnötigen Kosten. Die Arbeit zeigt, wie FAAS und Infrastructure as Code ineinandergreifen, um einen robusten, asynchronen Bereitstellungsprozess umzusetzen.

Ist-Situation

In der aktuellen Praxis existiert genau eine gemeinsame Testumgebung. Änderungen landen dort erst, nachdem sie in den Hauptzweig gemerged wurden. Wer eine Änderung vorher ausprobieren möchte, muss sie entweder lokal starten oder sich von Hand eine Test-VM in der AWS Management Console zusammenklicken.

GitLab bietet mit «Review Apps» zwar bereits dynamische Umgebungen pro MR an, inklusive URL-Anzeige im MR und automatischem Stoppen. Review Apps steuern aber nur den Lebenszyklus in GitLab, die eigentliche Bereitstellung auf AWS fehlt.

Problemanalyse der aktuellen Situation

Die gemeinsame Testumgebung und die manuellen Test-VMs bringen folgende Probleme mit sich:

• Gegenseitiges Überschreiben: Laufen mehrere Merge Requests parallel, überschreibt die zuletzt deployte Änderung alle anderen. Ein isoliertes Testen ist nicht möglich.
• Späte Fehlererkennung: Da Änderungen erst nach dem Merge sichtbar werden, fallen Fehler erst auf, wenn sie bereits im Hauptzweig sind.
• Vergessene Ressourcen: Von Hand erstellte Test-VMs werden nach dem Review gerne vergessen und verursachen laufende Kosten.
• Fehlende Reproduzierbarkeit: Manuell erstellte Test-VMs sind «Snowflake-Server», die sich nicht identisch wiederherstellen lassen.
• Zu weitreichende Rechte: Würde direkt aus dem CI-Job bereitgestellt, bräuchte der Runner weitreichende EC2-Rechte.

Methodik

Die Umsetzung erfolgt nach agilen Prinzipien in Anlehnung an das SCRUM-Framework mit drei Sprints. Der Product Backlog wird als GitLab Issues geführt und nach MoSCoW priorisiert. Zur Visualisierung des Arbeitsfortschritts wird das Issue Board von GitLab als Kanban-Board eingesetzt. Jeder Sprint wird mit einem Review und einer kurzen Retrospektive abgeschlossen.

Relevanz / Motivation

Relevanz Die Entwicklungsteams der Ronova arbeiten parallel an mehreren Merge Requests, teilen sich aber eine einzige Testumgebung. Damit Reviewer Änderungen isoliert und frühzeitig prüfen können, ohne dass dabei vergessene Test-VMs Kosten verursachen, ist es erforderlich, die Bereitstellung von Review-Umgebungen vollständig zu automatisieren.

Motivation Ich arbeite privat mit GitLab CI, Terraform und AWS und möchte genau diesen Workflow auch für meine eigenen Projekte nutzen. Zudem greifen hier FAAS und IaC ineinander, und asynchrone Verarbeitung, Nebenläufigkeit und Aufräumlogik sind keine Trivialität. Genau diese Herausforderung reizt mich.

Out-of-Scope

Für dieses Projekt sind folgende Punkte out of Scope:

• Die Entwicklung einer produktiven Webanwendung (es wird nur eine kleine Demo-Anwendung als Testobjekt verwendet)
• Produktive Umgebungen sowie Deployments in Produktion
• Datenbanken oder persistente Daten innerhalb der Review-Umgebungen
• Eigene Domains und TLS-Zertifikate pro Review-Umgebung
• Andere CI/CD-Systeme als GitLab CI/CD

Projektorganisation

Name	Rolle	Kontaktinformationen	GitLab User	GitHub User
Ramon Schmocker	Projektleiter	[email protected]	@4G0NYY	@4G0NYY
Corrado ???	Fachdozent PRJ	???	@???	@???
Armin Dörzbach	Fachdozent IaC & FAAS	[email protected]	@armindoerzbachtbz	@armindoerzbachtbz
Thanam Pangri	Lehrgangsleiter	[email protected]	@pat-teacher	@pat-teacher