Wie sieht eine gute CI-Pipeline für einen Backend-Service aus?

Sie läuft bei jedem Push, liefert Feedback in unter zehn Minuten und blockiert den Merge bei Fehlschlag. Sortier die Stufen von billig nach teuer: Lint und Typprüfungen, Unit Tests, dann Integrationstests gegen echte Abhängigkeiten in Containern, dann ein Build-Artefakt, das du weiterreichst statt es pro Umgebung neu zu bauen. Halt sie deterministisch, quarantäniere flaky Tests statt blind zu wiederholen, und mach dieselben Prüfungen lokal ausführbar.

Die erste Eigenschaft ist Geschwindigkeit, denn eine Pipeline, die vierzig Minuten braucht, ist eine, um die Leute herumarbeiten. Ich will Lint und Typprüfungen, die innerhalb einer Minute scheitern, Unit Tests in ein paar, und das Ganze unter zehn. Die Stufen gehen also von billig nach teuer: statische Prüfungen, Unit Tests, dann Integrationstests gegen echtes Postgres und Redis in Containern statt gegen Mocks, denn die Bugs, die mich interessieren, leben an der Grenze. Dann baut sie ein Artefakt, ein Container Image mit dem Commit-SHA getaggt, und jede Umgebung danach deployt genau dieses Image. Pro Umgebung neu zu bauen heißt, dass das Getestete nicht das Ausgelieferte ist. Bei flaky Tests bin ich streng: Ein automatischer Retry versteckt eine echte Race, ein flaky Test kommt also in Quarantäne und jemand ist dafür verantwortlich, ihn diese Woche zu reparieren. Und ich will dieselben Kommandos lokal ausführbar haben, meist hinter einem Makefile, denn per Commit-Push zu debuggen, um zu sehen was die CI sagt, ist eine elende Art, einen Nachmittag zu verbringen.