Schneller liefern mit weniger

Ein Build wird langsam, wie ein Zimmer voll wird: Niemand entscheidet, es vollzustellen. Unserer ging in etwa einem Jahr von vier auf vierzehn Minuten, eine vernünftige Ergänzung nach der anderen, und jede hatte an dem Tag, an dem sie kam, ein gutes Argument hinter sich.

Im April haben wir aufgehört hinzuzufügen und angefangen zu lesen. Nicht zu profilen. Zu lesen. Jeden Schritt der Pipeline, laut, mit der Frage was geht kaputt, wenn das weg ist. Zwei Drittel der Antworten waren irgendeine Variante von «nichts, aber es fühlt sich sicherer an».

vorher

14:20

Median eines CI-Laufs auf main

nachher

3:05

gleiche Commits, gleicher Runner

Build-Werkzeuge

6 → 2

gezählt: alles mit eigener Konfigurationsdatei

Was die Zeit wirklich gekostet hat#

Die ehrliche Antwort war nicht der Compiler. Es waren die Schichten drumherum: ein Wrapper, der nur existierte, um den Bundler zu konfigurieren, ein zweiter Test-Runner für eine einzige Alt-Suite, ein Lint-Durchlauf, der im Type-Check nochmals lief, weil niemand sicher war, ob der erste gelaufen war.

Die Build-Zeile ist leer, weil der Build jetzt im Deploy stattfindet, einmal, statt zweimal in der CI und nochmals auf der Plattform. Das war der grösste Einzelgewinn, und er kam davon, einen Job zu löschen, nicht davon, einen zu optimieren.

Das Installieren war die leichte Hälfte#

Der Wechsel auf pnpm mit gesperrtem Store brachte die Installation von drei Minuten auf vierzig Sekunden, und zwar dadurch, dass nichts mehr kopiert wird: ein inhaltsadressierter Store plus Hardlinks heisst, die zweite Installation derselben Abhängigkeit ist ein Link und kein Download.

# was der Runner jetzt tut, vollständig
corepack enable
pnpm install --frozen-lockfile
pnpm lint && pnpm typecheck && pnpm test

Die Regel, die geblieben ist#

Löschen ist einmal leicht. Gelöscht zu bleiben ist der schwere Teil, denn das nächste Werkzeug kommt immer mit einem echten Problem im Gepäck. Also haben wir aufgeschrieben, welchen Test es bestehen muss, und der ist mit Absicht mühsam:

1. 01
   Den Fehler benennen

   Welcher konkrete Bug hat es in die Produktion geschafft, oder hätte es getan? «Best Practice» ist kein Fehler. Wenn niemand auf den Vorfall zeigen kann, ist das Werkzeug eine Versicherung gegen ein ausgedachtes Risiko.

2. 02
   Benennen, was es ersetzt

   Zusätzliche Werkzeuge summieren sich. Was neu dazukommt, übernimmt entweder einen Schritt, oder es kommt nicht herein. Zwei Linter entscheidet niemand mit Absicht.

3. 03
   Sein Budget benennen

   Sekunden CI-Zeit, und eine Zahl, die wir einen Monat später nachprüfen. Ein Schritt, der über sein Budget hinauswächst, geht zurück in die Prüfung, statt still zur neuen Normalität zu werden.

Seither wurden drei Werkzeuge vorgeschlagen. Eines kam durch. Das Verhältnis fühlt sich richtig an: Das Ziel war nie null Werkzeuge, sondern Werkzeuge, die sich jedes für sich erklären können.