Warum wir unsere CI auf kurzlebige Runner umgestellt haben
Langlebige Build-Maschinen waren langsam, unzuverlässig und ein Sicherheitsrisiko. Kurzlebige Runner lösen alle drei Probleme.
Bis zu diesem Frühjahr liefen unsere CI-Pipelines auf zwölf langlebigen Build-Maschinen. Mit der Zeit sammelten sich dort Caches, verwaiste Prozesse und Zugangsdaten an, und alle paar Wochen schlug ein Build aus Gründen fehl, die niemand nachstellen konnte.
Ein Job, eine Maschine
Jetzt starten wir für jeden Job eine frische virtuelle Maschine und löschen sie, sobald der Job fertig ist. Abhängigkeiten kommen aus einem gemeinsamen, schreibgeschützten Cache, daher wurden die Builds nicht langsamer. Die mittlere Pipeline-Dauer sank sogar von 14 auf 9 Minuten.
Der Sicherheitsgewinn war genauso wichtig: Kein Secret überlebt länger als einen einzelnen Job, und ein kompromittierter Build kann den nächsten nicht beeinflussen.
Instabile Builds gingen um rund 80 Prozent zurück. Die verbleibenden Fehler sind jetzt echte Testfehler, und genau das soll eine CI melden.