Der lineare Ingenieur Mufeez Amjad hat einen detaillierten Bericht darüber veröffentlicht, wie das Unternehmen seine kontinuierliche Integrationspipeline überarbeitet hat, nachdem KI-Codierungsagenten CI zum schlimmsten Engpass gemacht hatten – indem er die Wartezeit für Pull-Requests von mehr als sechs Minuten auf etwas mehr als fünf Minuten verkürzte, während sich seine Testsuiten seit Jahresbeginn fast vervierfacht haben.
Der Beitrag, der am 21. September im Engineering-Blog von Linear veröffentlicht wurde, begann, wie so oft, mit einem knappen Ticket von oben. Anfang dieses Jahres öffnete Amjad Linear und stellte fest, dass Tuomas, der CTO des Unternehmens, ihm ein Problem mit der Überschrift „CI-Kosten sind hoch“ zugewiesen hatte – und ihn dabei gebeten hatte, CI schneller zu machen. Weitere Informationen zu dieser Geschichte finden Sie in unserer laufenden KI-Branchenberichterstattung.
Wenn Agenten die Validierung übertreffen
Das Problem ist strukturell und nicht zufällig. „Agenten haben die Auslieferung von Code exponentiell beschleunigt“, schrieb Amjad, „aber die Validierung dieser Änderungen konnte nicht ganz mit der gleichen Geschwindigkeit Schritt halten.“ Jeder Pull-Request muss immer noch CI durchlaufen, sodass CI mit zunehmender Entwicklung zum Engpass wird – was die Infrastrukturkosten in die Höhe treibt und Entwickler und ihre Agenten länger auf Feedback warten lässt.
Linear optimiert für zwei Metriken: wie lange ein PR auf CI wartet und wie viel Runner-Zeit er verbraucht. Die Ergebnisse nach monatelanger Arbeit: Obwohl sich die Testsuiten seit Januar fast vervierfacht haben, sank die Wartezeit für Pull-Requests von mehr als sechs Minuten auf etwas mehr als fünf, und die Läuferzeit pro Test wurde ungefähr halbiert.
Die Arbeit ließ sich grob in vier Kategorien einteilen: verbesserte Infrastruktur und Tools, optimierte Jobs, die andere Arbeiten blockieren, reduzierte wiederholte Einrichtungsschritte und effizientere Testausführung. Die Codebasis von Linear besteht hauptsächlich aus TypeScript, viele der Optimierungen gelten jedoch für alle Sprachen und Toolketten.
Schnellere Maschinen und ein nativer Compiler
Einige der ersten Erfolge erforderten fast keine Optimierung des CI selbst. Die Verlagerung von Arbeitslasten von GitHub Actions auf Läufer von Drittanbietern mit schnelleren CPUs, leistungsstärkerem Speicher und besserer Cache-Infrastruktur hat sich sofort ausgezahlt: In einem vergleichbaren Vergleich der beiden Tage auf beiden Seiten der Umstellung liefen Jobs im Durchschnitt 34 % schneller, wobei einige Arbeitslasten wie „tsc“ um 52 % zurückgingen.
Die Modernisierung der Toolchain trug zum Erfolg bei. Durch den Wechsel zu „tsgo“, dem nativen TypeScript-Compiler, konnte der wöchentliche Median der Typprüfung um 73 % gesenkt werden – groß genug, um den Engpass bei der Typprüfung vollständig zu beseitigen.
Linting ohne das Typdiagramm
Linting war ein weiteres frühes Ziel. Eine Handvoll benutzerdefinierter ESLint-Regeln von Linear hingen von TypeScript-Typinformationen ab, was dazu führte, dass jeder Lint-Lauf vor der Auswertung das vollständige Typdiagramm erstellen musste – was Linting zu einer der speicherintensivsten CI-Jobs machte.
Das Team hat die Regeln neu geschrieben, um eine statische Analyse des abstrakten Syntaxbaums zu verwenden und funktionsähnliche Konstrukte und Schutzmuster ohne Typinformationen zu identifizieren. Dadurch konnte ESLint auf TypeScript verzichten, wodurch die API-Lint-Zeit um 68 % und die Lint-Zeit für das gesamte Repository um 55 % reduziert wurde, wobei die Speichernutzung erheblich sank. Es erleichterte auch die spätere Migration zu Oxlint, was die für das Flusen aufgewendeten Minuten der CI-Läufer weiter reduzierte.
Den kritischen Pfad verkürzen
Da einzelne Prüfungen schneller erfolgten, verkleinerte Linear die Lösung und behandelte CI als System. Das lenkte die Aufmerksamkeit auf die kleinen Jobs, die vor allem anderen stehen – Pfadänderungserkennung und Testergebnis-Cache-Prüfungen, die auf Jobebene erfolgen, was bedeutet, dass keine der acht API-Test-Shards gestartet werden kann, bis sie abgeschlossen sind.
Die Korrekturen waren granular, aber additiv. Durch die Begrenzung der Abruftiefe wurde die Zeit des langsamsten Gates von 94 Sekunden auf 20 Sekunden verkürzt. Durch die vollständige Entfernung des Checkouts aus Jobs, die nie einen funktionierenden Baum benötigten, wurden diese von 27 Sekunden auf 7 Sekunden reduziert. Ein spärliches, blobloses Checkout mit begrenztem Verlauf sparte weitere etwa 11 Sekunden für Push- und Merge-Queue-Ereignisse. Insgesamt sank die mittlere Dauer des Änderungserkennungsjobs von 26 Sekunden auf 8, sein p90 von 31 auf 12 und seine langsamste Ausführung von 138 Sekunden auf 37.
Auch an der Checkout-Zuverlässigkeit musste gearbeitet werden: Da sich die Drittanbieter-Läufer außerhalb des GitHub-Netzwerks befinden und auf eine direkte IP-Verbindung angewiesen sind, kam es gelegentlich zu Verzögerungen bei den Abrufvorgängen aufgrund zeitweiliger Verbindungsverschlechterungen. Linear hat „actions/checkout“ durch eine eigene zusammengesetzte Aktion ersetzt, die es mit Backoff erneut versucht, „GIT_HTTP_LOW_SPEED_LIMIT“ und „GIT_HTTP_LOW_SPEED_TIME“ festlegt, sodass eine blockierte Verbindung nach etwa 30 Sekunden abbricht, anstatt zu hängen, und einen Checkout-Cache verwendet, der einen dauerhaften Git-Spiegel auf einer Sticky-Disk hält.
Eine subtile Korrektur beseitigte verschwendete Zeit in der Zusammenführungswarteschlange: Cache-Markierungen wurden als Teil der abschließenden Prüfung vor dem Zusammenführen geschrieben, sodass ein PR auch nach bestandenen Tests in der Warteschlange bleiben konnte. Durch das Verschieben dieses Schreibvorgangs in einen Job ohne Gating konnte der Zusammenführungspfad für jede API-Pull-Anfrage und jeden Eintrag in der Zusammenführungswarteschlange um 42 Sekunden verkürzt werden. Zusammen haben diese Änderungen die erforderlichen Überprüfungen für API-PRs bei Cache-Fehlern etwa eine Minute verkürzt und gleichzeitig die Anzahl der Runner-Starts verringert.
Weniger verschwendete Sekunden pro Job
Die letzte Kategorie betrifft die Rüstkosten, die bei jedem Auftrag wiederholt werden. Jeder API-Test-Shard benötigte bei jedem Durchlauf 7 bis 8 Sekunden für die Installation desselben Postgres-Clients mit apt; Durch die Verschiebung in ein kleines CI-Basis-Image neben Node konnten die Shards betriebsbereit gestartet werden. Das Team fügte dem Image später native Build-Header hinzu, nachdem es festgestellt hatte, dass es beim Herunterladen während des Setups gelegentlich zu Hängenbleiben kommen konnte.
Warum es Anklang fand
Der Beitrag traf bei Entwicklern einen Nerv: Er erreichte die Titelseite von Hacker News und erhielt innerhalb eines Tages rund 250 Punkte und rund 280 Kommentare. Die Reaktion ist leicht zu erklären: Die Erfahrung von Linear nennt die Kosten der KI-gestützten Entwicklung, mit denen die meisten Ingenieursorganisationen erst jetzt konfrontiert werden. Agenten, die Pull-Requests innerhalb von Minuten generieren, warten immer noch auf Validierungspipelines, die auf den menschlichen Rhythmus ausgelegt sind, und jede Minute dieser Wartezeit wird auf alle parallel arbeitenden Agenten vervielfacht.
Die Lehre aus der Überarbeitung von Linear ist, dass der Engpass behoben werden kann, aber nur durch die unrühmliche Anhäufung vieler kleiner Korrekturen – schnellere Läufer, günstigere Typprüfungen, Lint-Regeln auf Syntaxebene, begrenzte Abrufe, robuste Checkouts, vorgefertigte Bilder – und nicht durch eine einzelne Wunderwaffe.
---
Der KI einen Schritt voraus seinErhalten Sie die neuesten KI-Nachrichten, Analysen und Durchbrüche – alles an einem Ort.
Weitere KI-Neuigkeiten lesen →
