CI-Pipeline beschleunigen: Caching, Parallelisierung, Flakes.
CI-Pipeline beschleunigen: Caching, Parallelisierung, was sonst noch hilft
Eine CI-Pipeline, die 20 Minuten läuft, wird umgangen. Eine, die 3 Minuten braucht, wird genutzt.
Warum Pipeline-Geschwindigkeit zählt
Entwickler warten nicht 20 Minuten auf ein grünes Build-Signal. Sie pushen, wechseln den Kontext, und schauen eventuell nach einer Stunde nochmal. Das verlangsamt Feedback-Loops und verleitet dazu, größere Commits zu machen – was Reviews schwerer macht.
Eine schnelle Pipeline ist ein echter Produktivitätsmultiplikator.
Die häufigsten Zeitfresser
Dependency-Installation ohne Caching. Tests, die seriell laufen, obwohl sie parallel könnten. Docker-Images, die jedes Mal neu gebaut werden. Tests, die externe Services aufrufen statt Mocks zu nutzen.
Caching richtig einsetzen
GitHub Actions, GitLab CI, Bitrise – alle haben Cache-Mechanismen. Das Muster: Cache-Key auf den Hash der Dependency-Lock-Datei setzen (composer.lock, package-lock.json). Wenn die Lock-Datei sich nicht ändert, wird der Cache verwendet.
- uses: actions/cache@v3
with:
path: vendor
key: ${{ hashFiles('composer.lock') }}
Test-Parallelisierung
PHPUnit kann Tests parallel laufen lassen (paratest). Jest hat --maxWorkers. Das allein kann eine Test-Suite von 10 auf 3 Minuten bringen.
Selektives Testing
Nicht bei jedem Commit alle Tests laufen lassen. Geänderte Files analysieren, nur betroffene Test-Suites triggern. Das ist aufwändiger einzurichten, aber extrem wirkungsvoll.
Checkliste CI-Pipeline-Optimierung
Dependency-Caching mit Lock-File-basiertem Cache-Key
Docker-Layer-Caching konfiguriert
Tests parallelisiert
Externe Services in Tests durch Mocks ersetzt
Pipeline-Stage-Zeiten gemessen und dokumentiert
Nur betroffene Tests bei kleinen Changes triggern
CI-Pipeline zu langsam?
markom.digital optimiert CI/CD-Pipelines – messbar, mit vorher/nachher Vergleich.
