Lineární inženýr Mufeez Amjad zveřejnil podrobnou zprávu o tom, jak společnost přepracovala svůj kontinuální integrační kanál poté, co kódovací agenti AI změnili CI na nejhorší překážku – zkrátili dobu čekání na žádost o stažení z více než šesti minut na něco málo přes pět, zatímco její testovací sady se od začátku roku téměř zčtyřnásobily.

Příspěvek zveřejněný na inženýrském blogu společnosti Linear 21. září začal, jak tyto věci často dělají, strohým lístkem shora. Začátkem tohoto roku Amjad otevřel Linear, aby zjistil, že Tuomas, technický ředitel společnosti, mu přidělil problém s názvem „Náklady na CI jsou vysoké“ – a požádal ho, aby zrychlil CI, když už je u toho. Další kontext k tomuto příběhu naleznete v našem probíhajícím [oboru AI] (https://aibuzzwire.news).

Když agenti předběhnou validaci

Problém je strukturální, ne náhodný. "Agenti exponenciálně zrychlili odesílání kódu," napsal Amjad, "ale ověřování těchto změn nebylo úplně stejné." Každý požadavek na stažení musí stále projít CI, takže jak se vývoj zrychluje, CI se stává škrticím bodem – zvyšuje náklady na infrastrukturu a nechává vývojáře a jejich agenty čekat déle na zpětnou vazbu.

Lineární optimalizované pro dvě metriky: jak dlouho PR čeká na CI a kolik času runner spotřebuje. Výsledky po měsících práce: navzdory tomu, že se testovací sady od ledna téměř zčtyřnásobily, doba čekání na žádost o stažení klesla z více než šesti minut na něco málo přes pět a doba běhu na test se zkrátila zhruba na polovinu.

Práce v zásadě spadala do čtyř kategorií: vylepšená infrastruktura a nástroje, optimalizace úloh, které zajišťují další práci, omezení opakovaného nastavování a zefektivnění provádění testů. Kódová základna Linearu je primárně TypeScript, ale mnoho optimalizací platí napříč jazyky a nástrojovými řetězci.

Rychlejší stroje a nativní kompilátor

Některé z prvních zisků nevyžadovaly téměř žádnou optimalizaci samotné CI. Přesunutí zátěže z GitHub Actions na běžce třetích stran s rychlejšími procesory, výkonnějším úložištěm a lepší infrastrukturou mezipaměti se okamžitě vyplatilo: ve srovnání dvou dnů na obou stranách přepínače úlohy běžely v průměru o 34 % rychleji, přičemž některé zátěže, jako je `tsc` klesly o 52 %.

Modernizace toolchainu přispěla k vítězství. Přechod na `tsgo`, nativní kompilátor TypeScript, snížil týdenní medián typové kontroly o 73 % – dostatečně velký na to, aby se úzké hrdlo úplně přerušilo.

Lining bez typového grafu

Linting byl dalším raným cílem. Hrstka vlastních pravidel ESLint společnosti Linear závisela na informacích o typu TypeScript, což přinutilo každé spuštění lintu vytvořit úplný graf typu před jejich vyhodnocením – čímž se lintování stalo jednou z nejvíce paměťově náročných úloh CI.

Tým přepsal pravidla tak, aby používala statickou analýzu nad abstraktním stromem syntaxe a identifikovala funkční konstrukce a ochranné vzory bez jakýchkoli informací o typu. To umožnilo ESLint úplně vypustit TypeScript, čímž se zkrátila doba lintování API o 68 % a doba lintování celého úložiště o 55 %, přičemž využití paměti podstatně kleslo. Také to usnadnilo pozdější migraci na Oxlint, což dále zkrátilo CI-minuty strávené lintingem.

Zmenšení kritické cesty

Díky rychlejším individuálním kontrolám se Linear oddálil a zacházel s CI jako se systémem. To přitáhlo pozornost k malým úlohám, které stojí před vším ostatním – detekcí změny cesty a kontrolou mezipaměti výsledků testu, která brána na úrovni úlohy, což znamená, že žádný z osmi testovacích fragmentů API nemůže začít, dokud neskončí.

Opravy byly zrnité, ale aditivní. Omezení hloubky načítání trvalo nejpomalejší bráně z 94 sekund na 20. Úplné odstranění pokladny z úloh, které nikdy nepotřebovaly pracovní strom, zkrátilo tyto z 27 sekund na 7. Řídký, bez skvrn s omezenou historií ušetřil dalších 11 sekund pro události push a slučovací fronty. V souhrnu se střední doba trvání úlohy detekce změn snížila z 26 sekund na 8, její p90 z 31 na 12 a její nejpomalejší průběh ze 138 sekund na 37.

Spolehlivost služby Checkout také potřebovala zapracovat: protože provozovatelé třetích stran sedí mimo síť GitHub a spoléhají na přímé spojení IP, občasné zhoršování spojení občas zastavilo načítání. Linear nahradil `actions/checkout` svou vlastní složenou akcí, která se opakuje s backoffem, nastavuje `GIT_HTTP_LOW_SPEED_LIMIT` a `GIT_HTTP_LOW_SPEED_TIME` tak, aby se pozastavené připojení přerušilo po asi 30 sekundách místo zamrznutí, a používá mezipaměť pokladny, která udržuje trvalé zrcadlo git disku.

Jedna jemná oprava odstranila plýtvání časem slučovací fronty: značky mezipaměti byly zapisovány jako součást závěrečné kontroly před sloučením, takže PR mohl sedět ve frontě i poté, co prošly testy. Přesunutí tohoto zápisu do úlohy bez hradlování bylo oholeno 42 sekund od cesty sloučení pro každý požadavek na vytažení API a položku fronty sloučení. Dohromady tyto změny ubraly zhruba minutu z požadovaných kontrol API PR při chybách mezipaměti a zároveň snížily počet startů běžců.

Méně promarněných sekund na zakázku

Poslední kategorie napadených nákladů na nastavení se opakovala u každé zakázky. Každý testovací fragment API strávil 7 až 8 sekund instalací stejného klienta Postgres s apt při každém spuštění; přesunutí do malého základního obrazu CI vedle Node znamenalo, že úlomky mohly být připraveny ke spuštění. Tým později přidal do obrázku nativní záhlaví sestavení poté, co zjistil, že jejich stahování během instalace může občas přestat reagovat.

Proč to rezonovalo

Příspěvek zasáhl vývojáře: dostal se na titulní stránku Hacker News, během jednoho dne získal zhruba 250 bodů a kolem 280 komentářů. Reakce se dá snadno vysvětlit – zkušenosti společnosti Linear pojmenovávají náklady na vývoj podporovaný umělou inteligencí, se kterými se většina inženýrských organizací potýká teprve nyní. Agenti, kteří generují žádosti o stažení během několika minut, stále čekají na ověřovacích kanálech navržených pro lidskou kadenci a každá minuta tohoto čekání se násobí u každého paralelně pracujícího agenta.

Ponaučení z přepracování Linearu je, že úzké hrdlo je pohyblivé, ale pouze díky neokoukanému nahromadění mnoha malých oprav – rychlejších běžců, levnějších typových kontrol, pravidel lintování na úrovni syntaxe, omezeného načítání, odolných pokladen, předem sestavených obrázků – spíše než pomocí jediné stříbrné kulky.

---

Stay Ahead of AI

Získejte nejnovější zprávy, analýzy a průlomové informace o umělé inteligenci – vše na jednom místě.

Přečtěte si další zprávy o AI →