Wie Linear Cut die Wartezeit von mehr als 6 Minuten auf unter 5 Minuten verkürzte ()

Linear, das Projektmanagement-Tool, hat einen Engineering-Post mit dem Titel „CI-Kosten sind hoch“ veröffentlicht, und der Titel ist zutreffend: das Unternehmen erklärt, wie es seine Continuous-Integration-Wartezeit von mehr als 6 Minuten auf knapp über 5 Minuten verkürzte, während es gleichzeitig die Ausführungszeit pro Test halbiert hat. Der Artikel ist ein Lehrstück über Performance-Optimierung und sollte von jedem gelesen werden, der gesehen hat, wie CI-Pipelines durch das wachsende Codebasis verlangsamt wurden.

Das Problem war einfach. Die Entwickler von Linear brachten Code schneller in die Produktion ein, als das System ihn auf Fehler überprüfen konnte. Pull Requests mussten zwar weiterhin CI durchlaufen, aber da die Entwicklung beschleunigte, begann die Pipeline zu verlangsamen und wurde zu einem Engpass. Das erhöhte die Infrastrukturkosten und ließ Agenten länger auf Feedback warten, was dem Gegenteil von dem entspricht, was CI eigentlich tun soll.

Die vier Wege zu schneller CI

Vier unterschiedliche Ansätze wurden ausprobiert, jeder davon mit spezifischen Zahlen im Artikel aufgeschlüsselt, wie Linears Ingenieure von allen Seiten voranschritten.

1. Aufrüsten der Infrastruktur und der Werkzeuge
2. Optimierung der Jobs, die andere Arbeiten blockieren
3. Reduzierung wiederholter Einrichtungsschritte
4. Effizientere Testausführung

Die interessantesten Punkte sind die ersten beiden, da diese tatsächliche Systemänderungen erfordern, anstatt lediglich Code anzupassen. Die letzten beiden beziehen sich mehr auf Refactoring und Prozesse, machten aber dennoch einen Unterschied.

Aufrüsten der Maschinen

Linear erzielte seine ersten Erfolge, indem es seine CI-Workloads von GitHub Actions entfernte und sie auf Drittanbieter-Runner verschob, die schnellere CPUs, leistungsfähigeren Speicher und eine verbesserte Cache-Infrastruktur boten. Ein Vergleich von zwei Tagen vor und nach dem Wechsel zeigte, dass Jobs durchschnittlich 34 % schneller liefen. Einige Workloads, wie z. B. tsc, verzeichneten eine Verkürzung der Dauer um 52 %.

Das ist der Sieg, der man erzielt, wenn man aufhört, die langsamen Maschinen von jemand anderem zu mieten, und eigene kauft. Es bedurfte fast keiner Feinabstimmung der CI selbst, was selten vorkommt.

Der Compiler-Wechsel, der das Engpassproblem verschob (1)

Der nächste Compiler-Wechsel erfolgte. Linear wechselte zu tsgo, dem nativen TypeScript-Compiler, und dieser Wechsel reduzierte den wöchentlichen Median des tsc-Checks um 73 %. Die Reduktion war groß genug, um das Engpassproblem vollständig von der Typüberprüfung zu verlagern. (2)

Es fühlt sich wirklich wie Magie an, wenn man ein Werkzeug ändert und die Pipeline aufhört, durch einen Schritt verlangsamt zu werden, der einst den Großteil der Zeit in Anspruch nahm. Der Beitrag versucht nicht, den Umfang der Änderung herunterzuspielen — 73 % sind keine kleine Anpassung, sondern eine vollständige Transformation. (3)

„Hole nur das ab, was jede Aufgabe benötigt“ (4)

Linting ohne den Type Checker (5)

Die Behebung des Speicherproblems mit Linting war ein weiteres frühes Ziel. Mehrere von Linear’s benutzerdefinierten Lint-Regeln stützten sich auf TypeScript-Typinformationen, um eine Einschränkung durchzusetzen oder eine automatische Korrektur anzuwenden. Daher musste jede Lint-Ausführung den vollständigen Typgraphen erstellen, bevor diese Regeln ausgewertet wurden, und das machte Linting zu einem der speicherintensivsten CI-Jobs. (6)

ESLint eliminierte TypeScript, nachdem Linear statische Analyse auf dem abstrakten Syntaxbaum verwendete, um funktionsähnliche Strukturen und Wachmuster zu erkennen, ohne Typinformationen zu benötigen. Dieser Ansatz kürzte die API-Lint-Zeit um 68 %, reduzierte die vollständige Repository-Lint-Zeit um 55 % und senkte den Speicherverbrauch erheblich. (7)

Der Moment der Erleichterung kam nach dem Wechsel von Linear zu Oxlint, was die von Linting verbrauchten CI-Runner-Minuten kürzte. (8)

Die Behebung des Checkout-Hangs (9)

Der beste Teil der Geschichte ist die Behebung des Checkout-Problems. Nachdem Linear das System geändert hatte, auf dem es läuft, stellte das Unternehmen fest, dass das Auschecken von Code länger dauerte und gelegentlich zum Stillstand kam. Da Third-Party-Runner außerhalb von GitHubs Netzwerk leben, sind sie auf eine direkte IP-Verbindung angewiesen, um GitHub zu erreichen. Diese Verbindung war laut den Erkenntnissen des Anbieters die Ursache für die Stillstände. (10)

Mehrere von Linear’s Workflows beginnen mit einem Checkout, sodass ein gestoppter Fetch die gesamte CI-Ausführung verzögern konnte. Linear reagierte, indem es actions/checkout durch ein zusammengesetztes Action von eigener Hand ersetzte, das mit Backoff wiederholte und GIT_HTTP_LOW_SPEED_LIMIT und GIT_HTTP_LOW_SPEED_TIME festlegte, sodass eine gestoppte Verbindung nach etwa 30 Sekunden abbricht anstatt zum Stillstand zu kommen. Es verwendete außerdem den Checkout-Cache, der ein persistentes Git-Mirror auf einem Sticky-Disk speichert. (11)

Weniger Builds führten dazu, dass ein Job auf dem kritischen Pfad untätig blieb, während der Checkout seine Zeit brauchte, um fertig zu werden.

Die Merge Queue Fix

Linear identifizierte Jobs auf dem kritischen Pfad, die nicht notwendig waren. Das Unternehmen schrieb Cache-Marker als Teil der abschließenden Prüfung vor dem Mergen, was bedeutet, dass ein Pull Request auch dann in der Merge-Queue verbleiben konnte, nachdem seine Tests bestanden hatten. Das Verlag dieses Schreibvorgangs in einen Job, der nach dem Ende der Test-Shards ausgeführt wird, aber nichts blockiert, sparte 42 Sekunden für jeden API-Pull Request und Merge-Queue-Eintrag.

Die kombinierten Anpassungen reduzierten die Prüfzeit für API-Pull Requests bei Cache-Fehlern um etwa eine Minute und reduzierten auch die Anzahl der Runner-Starts.

Was das für Sie bedeutet

Jeder, der CI-Pipelines erstellt, sollte diese Geschichte lesen, da die Probleme, mit denen Linear konfrontiert war, universell sind. CI-Engpässe entstehen, wenn Pipelines lange dauern, um zu beginnen, lange laufen und lange dauern, bis sie fehlschlagen. Linear hat jede dieser Dimensionen ins Visier genommen, und die Ergebnisse sind greifbar.

CI-Performance ist ein Systemproblem, kein Codeproblem. Es spielt keine Rolle, wie schnell Ihre Tests laufen, wenn Ihre Pipeline die Hälfte ihrer Zeit damit verbringt, einen Runner zu starten oder ein Repository herunterzuladen — die Tests sind nutzlos. Die eigentliche Aufgabe besteht darin, herauszufinden, wo die Zeit verschwendet wird, und es zu beseitigen.

Linear ging mit Bedacht und Überlegung vor. Es tastete sich zuerst ab, gab dem Problem einen Namen und ging von mehreren Seiten gleichzeitig vor. Der Beitrag spricht offen darüber, was funktioniert hat und was nicht, und vermittelt den Eindruck eines Teams, das wirklich das Problem lösen wollte, anstatt einfach nur einen Blog-Post zu veröffentlichen.

Die Geschichte zeigt, dass Performance-Optimierung nicht aus dem Nichts entsteht. Sie wird aus einer langen Kette kleiner, schrittweiser Änderungen aufgebaut, die schließlich zu einem großen Ergebnis führen. Linears CI-Pipeline ist jetzt schneller und kostengünstiger, und das Unternehmen widmete einige Monate, um diesen Zustand zu erreichen.

Dieser Beitrag bietet einen Einblick in die Reibung, die sich in einer Pipeline ansammelt, während sich eine Codebasis erweitert, und er demonstriert, was passiert, wenn Sie diese Reibungspunkte messen und sie einzeln angehen. Wenn Sie CI für eine wachsende Codebasis zusammenstellen, lohnt es sich, sich das anzusehen.

Hohe CI-Kosten sind nicht einfach so entstanden; sie wurden lediglich entstehen gelassen. Linear akzeptierte diesen Weg nicht. Stattdessen wurde gemessen, optimiert und die Ergebnisse veröffentlicht, was zeigte, dass der richtige Weg für die Bearbeitung von Engineering durch Messung und Transparenz und nicht durch Akzeptanz geht.

Quelle: „KI-Programmierung hat CI zu einem Engpass gemacht, daher haben wir unseres überarbeitet, um Schritt zu halten“, linear.app.