Wie würdest du entscheiden, welche Tests in welcher Stufe der CI-Pipeline laufen?

Ordne die Stufen nach Kosten und Feedback-Geschwindigkeit. Bei jedem Commit Linting und Unit-Tests, Ziel wenige Minuten. Bei Pull Requests kommen Integrations- und Contract-Tests dazu. Nach dem Deployment in eine geteilte Umgebung laufen Smoke-Tests als Promotion-Gate. Die volle Regressionssuite und langsamere Checks wie Performance und Barrierefreiheit laufen nachts oder vor dem Release.

Ich entwerfe es danach, wie lange ein Entwickler tatsächlich wartet, und das ist nicht lange. Bei jedem Commit: Linting, statische Analyse und Unit-Tests, und ich halte das unter etwa fünf Minuten, denn darüber hinaus wechseln Leute den Kontext und das Feedback verliert den Großteil seines Werts. Beim Pull Request: Integrationstests gegen echte Abhängigkeiten in Containern, plus Contract-Tests, sodass alles, was einen anderen Service bricht, hier scheitert statt in einer geteilten Umgebung. Nach dem Deployment eine Smoke-Suite, die die Promotion absichert, vielleicht fünfzehn Tests, die belegen, dass der Build lebt und die kritischen Journeys funktionieren. Dann nachts der volle Regressionslauf plus die teuren Checks, also Performance, Barrierefreiheitsscans sowie Abhängigkeits- und Sicherheitsscans. Vor einem Release ein gezielter risikobasierter Durchgang über das Geänderte. Die Regel, die ich durchsetze, ist: wenn eine Stufe ein Gate ist, blockiert sie wirklich, und wenn sie nicht blockiert, sollte sie nicht als Gate präsentiert werden, denn eine dauerhaft rote Pipeline, durch die alle mergen, ist schlimmer als gar keine. Deshalb fliegen flaky Tests auch sofort aus den absichernden Stufen und sitzen in Quarantäne, bis sie repariert sind.