Welche Checks laufen in deinem Team in der CI auf einem Frontend-Pull-Request, und welche blockieren tatsächlich einen Merge?

Typische blockierende Gates sind Typecheck, Lint, Unit- und Komponententests, ein Produktions-Build und ein Bundle-Größenbudget. Accessibility-Scans und End-to-End-Tests laufen auch auf dem Pull Request, blockieren aber nur bei den kritischen Wegen. Alles Beratende, etwa ein Lighthouse-Score oder visuelle Diffs, meldet nur, ohne zu blockieren, denn ein Gate, das aus Gründen scheitert, die der Autor nicht beeinflussen kann, wird binnen eines Monats abgeschaltet.

Blockierend will ich Typecheck, Lint, die Unit- und Komponenten-Suite, einen echten Produktions-Build und ein Bundle-Größenbudget. Die sind deterministisch, sie scheitern aus Gründen, die der Autor beheben kann, und sie sind schnell. End-to-End-Tests laufen auf dem Pull Request, ich blockiere aber nur auf der kleinen Suite für den kritischen Pfad, der Rest läuft beim Merge, sonst wird die Queue zum Flaschenhals und Leute fangen an, auf Rot zu mergen. Beratend posten wir einen Lighthouse-Lauf und ein visuelles Diff als Kommentar. Auf einen Performance-Score blockiere ich bewusst nicht, weil er mit dem Rauschen der Runner schwankt, und ein flackerndes Gate wird umgangen und dann ignoriert. Jeder Pull Request bekommt außerdem einen Preview-Deploy, und das ist es, was Design und Produkt tatsächlich anschauen, und er fängt die Bugklasse, die nur in einem echten Build auftaucht, etwa eine Umgebungsvariable, die außerhalb der Entwicklung nie gesetzt wurde. Das Gate, das unterschätzt wird, ist das Größenbudget: es ist das Einzige, was verhindert, dass ein Bundle Abhängigkeit für Abhängigkeit nach oben driftet.