Viele Entwickler:innen kennen das: uneinheitliche Release-Prozesse, manuelle Deployments, fehlende Tests und Situationen, in denen neuer Code direkt von lokalen Laptops auf Live-Systeme kopiert wird. Unser Ziel ist ein anderer Ansatz – reproduzierbar, transparent und qualitätsgesichert. Dieser Artikel zeigt, wie ein neues Feature bei uns den Weg vom ersten Test bis zum Deployment durchläuft und welche Maßnahmen dafür sorgen, dass jede Änderung stabil, überprüft und sicher in Produktion gelangt.
Warum ein klarer CI/CD-Prozess entscheidend ist
Was moderne Entwicklung heute braucht
Entwicklungsteams benötigen Prozesse, die verlässlich funktionieren und wenig Raum für Interpretationen lassen. In vielen Organisationen sind die Abläufe historisch gewachsen, oft fragmentiert und abhängig von einzelnen Personen. Dadurch entstehen Fehlerquellen, unnötige Rückfragen und Unsicherheiten darüber, welche Version sich eigentlich auf welchem System befindet.
Ein klar definierter CI/CD-Prozess schafft hier Abhilfe. Er sorgt nicht nur für Qualität und Stabilität, sondern stärkt auch die Zusammenarbeit im Team. Wenn alle denselben Weg in Richtung Produktion nutzen, wird Wissen geteilt, Standards werden eingehalten und neue Teammitglieder finden sich schneller zurecht.
Was unser Prozess leisten soll
Unser Workflow folgt einem einfachen Ziel: Neue Features sollen konsistent, nachvollziehbar und ohne manuelle Sonderwege in Produktion gelangen. Dafür setzen wir auf:
- reproduzierbare Builds
- automatisierte Qualitätsprüfungen
- eindeutige Freigabeprozesse
- klare Rollenverteilungen
- möglichst geringe Fehleranfälligkeit
- gleiche Abläufe für alle Projekte
Damit bietet der Prozess genau das, was Entwickler:innen in ihrem Alltag erwarten: Stabilität, Transparenz und wenig Reibungsverluste.
Unser Weg vom Feature zur Produktion – der Überblick
Erstes Testen auf dem internen Testsystem
Bevor neuer Code überhaupt in Richtung Produktion wandert, wird er in einer internen Testumgebung geprüft. Das Besondere: Dieser Schritt erfolgt stets durch mindestens zwei Personen. Das 4-Augen-Prinzip stellt sicher, dass sowohl Funktionalität als auch Umsetzung nachvollziehbar und belastbar sind.
Durch diese frühe Validierung entsteht ein sauberer Ausgangspunkt für alles Weitere. Teams erkennen potenzielle Probleme früher, diskutieren aktiv über Code und hinterfragen technische Entscheidungen dort, wo sie am meisten bewirken: vor dem Merge.
Pull Request als verbindlicher Standard
Jede Änderung am Production Branch erfolgt ausschließlich über einen Pull Request. Direkte Commits sind ausgeschlossen und damit auch der Umweg an der CI/CD vorbei. Dieser Grundsatz schafft eine klare Linie im gesamten Projekt.
Ein Pull Request umfasst:
- alle Änderungen des Features
- eine inhaltliche Beschreibung
- die geplante Wirkung auf das Gesamtsystem
- den automatischen Start aller relevanten Tests
Mindestens eine weitere Person prüft den PR. Dieser Review umfasst nicht nur fachliche und technische Aspekte, sondern fördert den Dialog im Team. Neue Codeansätze, Design-Überlegungen oder Architekturentscheidungen werden aktiv besprochen. Zusätzlich unterstützt Claude AI beim Vergleich und der Bewertung der Änderungen.
Automatische Prüfungen für jeden Pull Request
Bevor ein PR überhaupt in den Production Branch gelangen kann, laufen mehrere automatisierte Prüfungen:
- PHP Unit Tests
- Functional Tests
- PHPStan
- Code Style Checks für PHP und TypoScript
Diese Tests bilden einen wichtigen Teil der Qualitätskontrolle. Sie reduzieren Fehlerquellen, schaffen konsistente Standards und verhindern, dass nicht freigegebene oder versehentlich eingebaute Änderungen den Weg in die Produktion finden.
Automatisiertes Deployment mit GitHub Actions und Deployer
Reproduzierbare und sichere Deployments
Sobald der code reviewt, geprüft und akzeptiert ist, wird er in den Production Branch gemergt. Von dort übernimmt die Deployment-Pipeline. Unsere Deployments erfolgen über GitHub Actions in Kombination mit Deployer – ein Setup, das kontrollierbare, saubere und konsistente Releases ermöglicht.
Die wichtigsten Vorteile:
- Builds laufen immer unter denselben Bedingungen
- keine individuellen Systeme oder lokalen Abweichungen
- einheitliche Abläufe unabhängig davon, wer das Deployment ausführt
- zentrale Verwaltung aller Zugriffe
- deutliche Reduzierung menschlicher Fehler
Damit kann jedes Teammitglied deployen, ohne eigene Serverzugänge besitzen oder komplexe manuelle Schritte ausführen zu müssen.
Der Deployment-Vorgang
GitHub Actions steuert den kompletten Prozess:
- Ausführen aller Build-Schritte
- Deployment via Deployer auf das Zielsystem
Ein wichtiges Sicherheitsnetz: Es kann ausschließlich Code aus dem Production Branch deployt werden. Ein versehentliches Ausrollen von Entwicklungsständen ist systemisch ausgeschlossen.
Rollbacks für maximale Stabilität
Trotz umfangreicher Tests kann es in seltenen Fällen zu unerwartetem Verhalten in der Live-Umgebung kommen. Daher ist ein schnelles Rollback ein essenzieller Bestandteil des Prozesses.
Mit Deployer ist dies problemlos möglich: Das vorherige Release wird automatisch bereitgehalten und kann jederzeit wiederhergestellt werden. Dadurch bleibt das System auch dann stabil, wenn ein neues Feature einmal Schwierigkeiten bereitet.
Kontinuierliche Weiterentwicklung – aktuell: E2E-Tests mit Playwright
Der Prozess ist kein statisches Konstrukt. Aktuell erweitern wir ihn um End-to-End-Tests mit Playwright. Diese ermöglichen realistische, browserbasierte Tests der gesamten Anwendung – inklusive Interaktionen, Formularen und komplexen UI-Abläufen.
Damit entsteht ein nächster Qualitätsschritt: Funktionen werden nicht nur isoliert, sondern auch im Zusammenspiel getestet. Ziel ist ein Setup, das Schritt für Schritt noch zuverlässiger wird und langfristig zusätzliche Sicherheit für größere Projekte bietet.
Fazit
Ein klarer CI/CD-Prozess schafft Sicherheit, Transparenz und eine verlässliche Grundlage für moderne Entwicklung. Von der ersten Prüfung auf dem Testsystem über Pull Requests und automatisierte Tests bis zum Deployment mit GitHub Actions und Deployer folgt jeder Schritt einem definierten Ablauf. Rollbacks, reproduzierbare Builds und der Ausbau mit Playwright E2E-Tests tragen dazu bei, dass neue Features zuverlässig in Produktion gelangen. Für Entwickler:innen entsteht damit eine Umgebung, die Qualität ernst nimmt – und sie im täglichen Arbeiten spürbar unterstützt.