Abstract
Die vorliegende Arbeit verfolgt das Ziel, einen umfassenden und optimierten CI/CDWorkflow für Laravel-basierte APIs zu entwickeln und zu evaluieren. Im Rahmen dessen erfolgt eine Identifikation und Implementierung von Methoden zur Maximierung der Testabdeckung und Performance. Um das definierte Ziel zu erreichen, werden im Rahmen dieser Arbeit verschiedene Teilaspekte einer eingehenden Untersuchung und Bearbeitung unterzogen.
Im Rahmen der vorliegenden Untersuchung ist zu ermitteln, welche Teststrategien sich am besten eignen, um eine umfassende Testabdeckung zu gewährleisten. Zudem ist zu klären, welche Best-Practices bei der Implementierung von Unit- und Integrationstests existieren.
Ein weiterer Fokus liegt auf der Optimierung der Testdurchführung sowie der CI/CDPipeline. Im Rahmen dessen erfolgt eine Untersuchung von Techniken und Tools zur Reduzierung der Testausführungszeit, wobei ein Schwerpunkt auf der parallelisierten Ausführung liegt. Des Weiteren werden Caching-Strategien für Dependencies und Build-Artefakte evaluiert und implementiert. Im Anschluss erfolgt eine Evaluierung der Auswirkungen der optimierten CI/CD-Prozesse.
Ausgangslage und Forschungsfrage
Continuous Integration und Continuous Deployment (CI/CD) verschieben Qualitätssicherung nach vorn: Statt Fehler erst kurz vor dem Release zu finden, entsteht nach jedem Commit eine schnelle Rückmeldung aus Build, Tests und Deployment.[1] In Web-API-Projekten sind diese Feedback-Schleifen besonders wichtig, weil Änderungen oft viele Clients betreffen und Fehler in Schnittstellen schnell produktiv werden.
Die Arbeit adressiert eine typische Ausgangslage: Eine bestehende Web-API ohne automatisierte Tests und ohne Pipeline. Daraus ergeben sich zwei zentrale Forschungsfragen: Welche Teststrategien liefern schnell eine hohe und verlässliche Abdeckung, und welche Maßnahmen verkürzen (oder stabilisieren) die Laufzeit einer CI/CD-Pipeline in der Praxis?
Nicht behandelt werden vollständige organisatorische DevOps-Transformationen oder herstellerspezifische Plattformvergleiche. Im Mittelpunkt stehen konkrete, übertragbare Bausteine: Testdesign, Testarten für Web-APIs und messbare Pipeline-Optimierungen im Kontext kontinuierlicher Auslieferung.[2]
Methodisches Vorgehen
Für die Testsuite wird ein mehrstufiger Ansatz gewählt: Unit-Tests decken reine Logik ohne Seiteneffekte ab, während Integrationstests das Verhalten der API inklusive Datenbankzustand prüfen. Bei der Testfallentwicklung dominieren Black-Box-Verfahren (z.B. Äquivalenzklassen, Grenzwertanalyse, bewusst gewählte Fehlerfälle), ergänzt durch ausgewählte White-Box-Aspekte dort, wo Datenflüsse oder Strukturmerkmale zentral sind.[3]
Für API-Tests werden Endpunkte entlang ihrer fachlichen Gruppierung strukturiert. Die Testumgebung nutzt eine separate Testdatenbank, generiert Mock-Daten über Factory-Mechanismen und kapselt Tests in Transaktionen, um reproduzierbare Zustände zu garantieren. Abhängigkeiten zu externen Services werden in Tests durch Stubs ersetzt, um Kosten, Latenz und Flakiness zu reduzieren.[4]
Zur Bewertung nicht-funktionaler Anforderungen wird ein Werkzeug für Last- und Performance-Tests eingesetzt. In der Umsetzung zeigt sich jedoch eine praxisrelevante Einschränkung: Rate-Limiting-Mechanismen, die an IP-Adressen gebunden sind, können lokale Lastgeneratoren ausbremsen und die Aussagekraft einzelner Lasttests begrenzen.
Die CI/CD-Pipeline wird in mehreren Konfigurationen verglichen: eine Baseline mit typischen Schritten (Checkout, Setup, Dependency-Installation, Datenbank-Migration, Tests, Cleanup), eine Variante mit Dependency-Caching sowie eine Variante mit zusätzlicher Parallelisierung der Testausführung (u.a. mit ParaTest).[5] Gemessen werden Durchlaufzeiten und Schwankungen über verschiedene Runner-Umgebungen (direkt auf Host-Hardware vs. Container-Runner vs. Cloud-Runner).