Was PHP Quality Gates sind

PHP Quality Gates sind automatische Prüfungen in der CI Pipeline, die jeder Commit bestehen muss, bevor er gemergt wird. Typische Gates sind statische Analyse mit PHPStan, ein Rector Trockenlauf, PHPUnit Tests mit Coverage und E2E Tests mit Cypress.

Fällt ein Gate durch, wird der Merge blockiert. Das klingt streng, macht Refactoring aber erst sicher. Wer Code umbaut, braucht eine Instanz, die sofort meldet, wenn sich Verhalten oder Typen ungewollt ändern. Die Pipeline übernimmt diese Rolle bei jedem Push, ohne müde zu werden und ohne Ausnahmen für Freitagnachmittag. Diese Seite zeigt, welche Gates in welcher Reihenfolge sinnvoll sind und wie sie in GitHub Actions und GitLab CI aussehen.

Bei uns entscheidet die Pipeline über jeden Livegang. Unsere Symfony und Sulu Plattform läuft durch PHPStan, Psalm, Rector und PHPUnit, die Oberfläche durch Cypress mit Cypress Cloud. Wir nutzen GitHub Actions und GitLab CI täglich und richten beide in Kundenprojekten ein. Roland Golla ist Cypress Ambassador und hat mit dem NCA TESTIFY Plugin einen Basistest für Websites gebaut, der mit einer Zeile in der Pipeline läuft.

Im PHP Consulting bauen wir eure Pipeline Schritt für Schritt auf. Beim PHP Refactoring sorgen die Gates dafür, dass jeder Umbau prüfbar bleibt. Für die Oberfläche begleiten wir euch im Bereich Cypress Testing. Die Werkzeuge stehen im Glossar zu PHPStan, PHPUnit und GrumPHP.

Refactoring heißt, Struktur zu ändern und Verhalten zu behalten. Ob das gelingt, weiß man nur, wenn etwas prüft. Ohne Pipeline hängt die Qualität davon ab, ob jemand daran denkt, lokal die Tests laufen zu lassen. Unter Zeitdruck passiert genau das nicht.

Quality Gates machen aus guten Absichten feste Regeln. Sie gelten für alle gleich, für den Senior Entwickler genauso wie für den Code, den ein KI Agent geschrieben hat. Und sie geben dem Team Mut. Wer weiß, dass die Pipeline Fehler sofort meldet, traut sich auch an alte Klassen, die seit Jahren niemand anfassen wollte.

Wichtig ist das Zusammenspiel. Kein einzelnes Werkzeug fängt alle Fehler. Statische Analyse findet Typfehler, Tests finden falsches Verhalten, E2E Tests finden kaputte Abläufe in der Oberfläche. Erst die Kombination ergibt ein Netz, durch das kaum noch etwas fällt.

Gute Pipelines prüfen zuerst das Schnelle und Billige und erst danach das Langsame und Teure. Fällt die Syntaxprüfung nach Sekunden durch, muss niemand zehn Minuten auf E2E Tests warten. Die Tabelle zeigt die Reihenfolge, die wir in PHP Projekten einsetzen.

In GitHub Actions legt ihr die Gates als Schritte in einem Workflow an. Jeder Schritt, der fehlschlägt, stoppt den Lauf. Mit einer Branch Protection Regel blockiert der rote Lauf den Merge des Pull Requests.

Die Cypress Tests laufen am besten in einem eigenen Job, der erst startet, wenn die schnellen Gates grün sind. Mit Cypress Cloud seht ihr Videos, Screenshots und instabile Tests über viele Läufe hinweg.

In GitLab CI ordnet ihr die Gates in Stages. Alle Jobs einer Stage laufen parallel, die nächste Stage startet erst, wenn die vorige grün ist. So bekommt ihr schnelles Feedback und spart Rechenzeit.

Das GitLab Format von PHPStan schreibt einen Code Quality Report. Die Meldungen erscheinen dadurch direkt im Merge Request. Im echten Projekt braucht das Image noch Composer und die passenden PHP Erweiterungen, die ihr am besten in einem eigenen Docker Image vorbereitet.

Die Pipeline ist die letzte Schranke, nicht die erste. Schneller ist es, wenn Fehler gar nicht erst gepusht werden. GrumPHP hängt sich als Git Hook vor jeden Commit und führt die schnellen Prüfungen lokal aus. Die langsamen Tests bleiben in der Pipeline.

Bei Legacy Projekten ist die Gesamtabdeckung oft niedrig und lässt sich nicht über Nacht heben. Eine feste Grenze für die Gesamtabdeckung würde jeden Merge blockieren. Besser ist Patch Coverage: Sie misst nur, ob die neuen und geänderten Zeilen durch Tests abgedeckt sind. So wird jeder Pull Request ein Stück besser, ohne dass das Team an den Altlasten scheitert.

Wer wissen will, ob die Tests auch wirklich etwas prüfen, ergänzt Mutation Testing mit Infection. Es verändert den Code gezielt und schaut, ob die Tests das bemerken. Weil es langsam ist, läuft es meist nachts oder nur für geänderte Dateien.

KI Coding Agents erzeugen Code schneller, als ein Mensch ihn lesen kann. Das ist ihre Stärke und gleichzeitig das Risiko. Ein Agent kann Logik beim Umbauen vereinfachen, Typen aufweichen oder Fehlermeldungen mit Ignore Kommentaren zum Schweigen bringen. Im Diff fällt das zwischen hundert Zeilen kaum auf.

Die Pipeline schaut sich jede Zeile an, egal wer sie geschrieben hat. Deshalb gilt bei uns die Reihenfolge: erst Quality Gates, dann KI im Alltag. Ohne grüne Pipeline gibt es keinen Agenten im Repository. Mit ihr wird KI zu einem echten Beschleuniger, weil jede Änderung sofort gegen Tests und statische Analyse läuft.

Ein zusätzliches Gate lohnt sich für KI Code besonders: eine Regel, die neue Ignore Kommentare und Einträge in der Baseline meldet. So fällt sofort auf, wenn ein Fehler versteckt statt behoben wurde. Mehr dazu beschreiben wir im Vibe Coding Consulting und beim AI Code Refactoring.

Wir bauen Pipelines für PHP Projekte seit vielen Jahren und betreiben sie für unsere eigene Plattform täglich. Die Bausteine findet ihr im Glossar.

Syntax prüft PHP Parallel Lint, den Stil Easy Coding Standard und der PHP Codesniffer. Statische Analyse läuft mit PHPStan und Psalm, Architekturregeln mit Deptrac. Modernisierung prüft Rector PHP im Trockenlauf. Tests laufen mit PHPUnit, parallel mit Paratest, gemessen über Patch Coverage und hinterfragt durch das Infection Framework. Testberichte macht otr-report lesbar. Lokal fängt GrumPHP Fehler vor dem Commit ab, Sicherheitslücken in Abhängigkeiten meldet Composer Audit. Ausgeliefert wird mit dem PHP Deployer.

Was Teams beim Aufbau einer Pipeline für PHP Projekte am häufigsten fragen.