GitOps in der Praxis: Der DevOps Lifecycle, Codeception-Tests und Kubernetes Deployments

Wenn wir von "Industrial Grade Web Development" sprechen, meinen wir nicht nur sauberen Code. Wir meinen den gesamten Lebenszyklus einer Software. Der größte Schwachpunkt vieler Web-Agenturen ist das Deployment.

Wer im Jahr 2026 noch Änderungen per FTP-Client auf einen Live-Server zieht oder hofft, dass nach dem Update-Klick im Backend alles funktioniert, provoziert Ausfallzeiten. Bei CloudWebDevs haben wir "Hoffnung" durch Automatisierung ersetzt. Wir arbeiten nach der Methodik des DevOps Lifecycle (visuell oft als Infinity Loop dargestellt) – einer Endlosschleife aus Continuous Integration (CI) und Continuous Delivery (CD).

Alles beginnt im Code-Repository. Wenn ein Entwickler Code für ein TYPO3-Projekt (z.B. neue Content Blocks oder ein Update) in GitLab pusht, startet die Pipeline.

1. Build & Static Analysis: Die GitLab Runner kompilieren Frontend-Assets (npm run build) und laden Abhängigkeiten (composer install --no-dev). Danach durchläuft PHPStan den Code. Fehlt ein Type-Hint? Die Pipeline bricht ab (Rot).
2. Automated Acceptance Testing (Codeception): Das ist der Schritt, der "Bastler" von Ingenieuren trennt. Reiner PHP-Code-Check reicht nicht. Wir nutzen Codeception (basiert auf einer Selenium/WebDriver-Architektur), um echte Nutzer-Szenarien im Browser zu simulieren.
   • Die Pipeline öffnet einen echten (headless) Browser in einer Staging-Umgebung.
   • Sie navigiert zur Startseite, füllt das Kontaktformular aus und klickt auf "Senden".
   • Sie prüft, ob das TYPO3-Backend erreichbar ist und spezifische Module laden. Schlägt auch nur ein UI-Test fehl, geht das Update niemals live.
3. Containerization (Docker): Nach erfolgreichem Test wird das gesamte Projekt (TYPO3 Core + unsere Extensions + Assets) in ein Immutable Docker Image gebacken und in unsere private Registry gepusht. Nichts wird jemals zur Laufzeit verändert.

Bevor der Code live geht, muss die Infrastruktur bereit sein. Wir nutzen Ansible, um unsere Server-Nodes, Load-Balancer und externen Datenbank-Cluster (MariaDB/Redis) deklarativ zu konfigurieren. Das garantiert, dass die Staging-Umgebung bitgenau der Produktionsumgebung entspricht.

Das versiegelte Docker-Image muss nun sicher an den Kunden ausgeliefert werden.

1. Deploy: Wir weisen unser Kubernetes (K8s) Cluster an, das neue Image-Tag auszurollen.
2. Zero-Downtime: Kubernetes startet die neuen Docker-Container parallel im Hintergrund. Erst wenn die neuen Pods an den Ingress-Controller signalisieren, dass sie vollständig hochgefahren sind ("Readiness Probe"), wird der Live-Traffic blitzschnell auf die neuen Container umgeleitet. Die alten Container werden beendet. Der Nutzer merkt von dem Update absolut nichts.
3. Rollback: Sollte trotz Codeception-Tests ein Fehler auftreten, ändern wir in GitLab das Image-Tag zurück. Kubernetes stellt in Sekunden den exakten, funktionierenden Zustand wieder her.

Der Wechsel zu einer echten GitOps-Architektur inkl. automatisierten UI-Tests bedeutet für unsere Kunden vor allem eines: Absolute Sicherheit. Wir hoffen nicht, dass eine Webseite funktioniert – wir beweisen es maschinell vor jedem einzelnen Deployment.