Vibe coding

Warum Pipeline-Geschwindigkeit ein echter Produktivitaetsfaktor ist

Eine Pipeline, die zwanzig Minuten laeuft, wird umgangen. Eine, die drei Minuten braucht, wird genutzt.

Wer nicht zwanzig Minuten auf ein gruenes Build-Signal warten will, pusht, wechselt den Kontext und schaut vielleicht erst nach einer Stunde wieder nach. Das verlangsamt Feedback-Loops und verleitet zu groesseren Commits, was Reviews wiederum erschwert.

Eine schnelle Pipeline ist ein echter Produktivitaetsmultiplikator.

Die haeufigsten Zeitfresser

Dependency-Installation ohne Caching, seriell laufende Tests, obwohl Parallelisierung moeglich waere, bei jedem Lauf neu gebaute Docker-Images, und Tests, die externe Services statt Mocks aufrufen.

Caching richtig einsetzen

Die gaengigen CI-Systeme bieten alle Cache-Mechanismen. Das Muster: Cache-Key auf den Hash der Lock-Datei setzen, sodass der Cache nur bei tatsaechlichen Aenderungen invalidiert wird.

Test-Parallelisierung

PHPUnit kann Tests ueber paratest parallel ausfuehren, Jest bietet dafuer die maxWorkers-Option. Allein das kann eine Test-Suite von zehn auf drei Minuten bringen.

Selektives Testing

Statt bei jedem Commit alle Tests laufen zu lassen, lassen sich geaenderte Dateien analysieren und nur betroffene Test-Suites triggern, aufwendiger einzurichten, aber sehr wirkungsvoll.

Checkliste: Dependency-Caching mit Lock-File-basiertem Cache-Key, Docker-Layer-Caching konfiguriert, Tests parallelisiert, externe Services in Tests gemockt, Pipeline-Stage-Zeiten gemessen, nur betroffene Tests bei kleinen Aenderungen.

Ein Beispiel aus der Praxis

Eine CI-Pipeline brauchte ueber zwanzig Minuten pro Durchlauf, hauptsaechlich weil bei jedem Commit alle Abhaengigkeiten neu heruntergeladen wurden. Die Einfuehrung eines simplen, auf der Lock-Datei basierenden Caches reduzierte diesen Schritt von acht Minuten auf unter dreissig Sekunden. Kombiniert mit paralleler Testausfuehrung sank die Gesamtzeit auf unter vier Minuten. Der wichtigste Effekt zeigte sich nicht in der reinen Zeitersparnis, sondern darin, dass Entwickler wieder anfingen, kleinere, haeufigere Commits zu pushen, statt Aenderungen zu buendeln, um Wartezeit zu sparen.

CI-Pipeline zu langsam? markom.digital optimiert CI/CD-Pipelines messbar, mit einem klaren Vorher-Nachher-Vergleich.

Weitere Beiträge