Inginerul liniar Mufeez Amjad a publicat o descriere detaliată a modului în care compania și-a reproiectat conducta de integrare continuă după ce agenții de codare AI au transformat CI în cel mai mare blocaj al său - reducând timpul de așteptare a solicitării de tragere de la mai mult de șase minute la puțin peste cinci, în timp ce suitele sale de testare aproape s-au dublat de la începutul anului.
Postarea, publicată pe blogul de inginerie al lui Linear pe 21 septembrie, a început, așa cum fac adesea aceste lucruri, cu un bilet concis de sus. La începutul acestui an, Amjad a deschis Linear pentru a descoperi că Tuomas, CTO al companiei, i-a atribuit o problemă intitulată „Costurile CI sunt mari” – și i-a cerut să facă CI mai rapid cât timp era la asta. Pentru mai mult context asupra acestei povești, consultați [acoperirea industriei AI] (https://aibuzzwire.news).
Când agenții depășesc validarea
Problema este structurală, nu întâmplătoare. „Agenții au făcut ca expedierea codului să fie exponențial mai rapidă”, a scris Amjad, „dar validarea acestor modificări nu a continuat în același ritm”. Fiecare solicitare de pull trebuie să treacă prin CI, astfel încât, pe măsură ce dezvoltarea accelerează, CI devine punctul de sufocare - crescând costurile de infrastructură și lăsând dezvoltatorii și agenții lor să aștepte mai mult feedback.
Linear optimizat pentru două valori: cât timp așteaptă un PR pentru CI și cât timp consumă. Rezultatele după luni de muncă: în ciuda faptului că seturile de teste aproape s-au dublat din ianuarie, timpul de așteptare a cererii de extragere a scăzut de la mai mult de șase minute la puțin peste cinci, iar timpul de alergare per test a fost redus cu aproximativ jumătate.
Lucrarea s-a împărțit în general în patru categorii: infrastructură și instrumente modernizate, optimizarea sarcinilor care închid alte lucrări, reducerea setărilor repetate și eficientizarea execuției testelor. Baza de cod a lui Linear este în primul rând TypeScript, dar multe dintre optimizări se aplică în diferite limbi și lanțuri de instrumente.
Mașini mai rapide și un compilator nativ
Unele dintre cele mai vechi câștiguri nu au necesitat aproape nicio optimizare a CI în sine. Mutarea încărcăturilor de lucru de pe GitHub Actions către utilizatori terți cu procesoare mai rapide, stocare de performanță mai mare și infrastructură cache mai bună a dat roade imediat: într-o comparație similară a celor două zile de ambele părți ale comutatorului, lucrările au rulat cu 34% mai rapid, în medie, unele sarcini precum `tsc` scăzând cu 52%.
Modernizarea lanțului de instrumente a agravat câștigul. Trecerea la `tsgo`, compilatorul nativ TypeScript, a redus mediana săptămânală a verificării tipului cu 73% - suficient de mare pentru a elimina blocajul complet de la verificarea tipului.
Listing fără graficul de tip
Liting a fost o altă țintă timpurie. O mână de reguli ESLint personalizate de la Linear depindeau de informațiile de tip TypeScript, ceea ce a forțat fiecare rulare de lint să construiască graficul de tip complet înainte de a le evalua - făcând linting una dintre cele mai intense lucrări CI de memorie.
Echipa a rescris regulile pentru a utiliza analiza statică peste arborele de sintaxă abstractă, identificând constructe asemănătoare funcțiilor și modele de gardă fără nicio informație de tip. Acest lucru a permis lui ESLint să renunțe complet la TypeScript, reducând timpul de scame API cu 68% și timpul de scame al depozitului complet cu 55%, utilizarea memoriei scăzând substanțial. De asemenea, a ușurat migrarea ulterioară la Oxlint, ceea ce a redus și mai mult numărul de minute ale alergătorului CI petrecute cu scame.
Reducerea căii critice
Cu verificări individuale mai rapide, Linear a micșorat și a tratat CI ca pe un sistem. Acest lucru a atras atenția asupra lucrărilor mici care stau în fața tuturor celorlalte - detectarea schimbării căii și verificările cache-ului rezultat al testului care se încadrează la nivel de job, ceea ce înseamnă că niciunul dintre cele opt fragmente de testare API nu poate începe până când se termină.
Remediile au fost granulare, dar aditive. Limitarea adâncimii de preluare a luat cea mai lentă poartă de la 94 de secunde la 20. Eliminarea completă a procesului de comandă din lucrările care nu au avut niciodată nevoie de un arbore funcțional le-a redus de la 27 de secunde la 7. O procedură rară, fără probleme, cu istoric limitat, a salvat încă 11 secunde ciudate pentru evenimentele push și merge-queue. În total, durata medie a sarcinii de detectare a modificărilor a scăzut de la 26 de secunde la 8, p90 de la 31 la 12 și cea mai lentă rulare de la 138 de secunde la 37.
Fiabilitatea checkout-ului a avut nevoie și de lucru: deoarece alergătorii terți stau în afara rețelei GitHub și se bazează pe o legătură IP directă, degradarea intermitentă a legăturii a blocat uneori transferurile. Linear a înlocuit `actions/checkout` cu propria sa acțiune compusă care reîncearcă cu backoff, setează `GIT_HTTP_LOW_SPEED_LIMIT` și `GIT_HTTP_LOW_SPEED_TIME`, astfel încât o conexiune blocată se întrerupe după aproximativ 30 de secunde în loc să se blocheze și folosește un cache git de checkout care oglindește un disc git persistent pe oglindă.
O remediere subtilă a eliminat timpul pierdut în coada de îmbinare: marcatorii cache erau scrisi ca parte a verificării finale înainte de îmbinare, astfel încât un PR putea sta în coadă chiar și după ce testele sale au trecut. Mutarea acelei scrieri într-o lucrare non-gate a redus 42 de secunde din calea de îmbinare pentru fiecare solicitare de extragere API și intrare în coada de îmbinare. Împreună, aceste modificări au luat aproximativ un minut de la verificările necesare pentru PR-urile API privind erorile din memoria cache, reducând în același timp pornirile de alergare.
Mai puține secunde pierdute pe job
Costul de configurare din ultima categorie atacată s-a repetat pentru fiecare lucrare. Fiecare fragment de testare API a petrecut 7 până la 8 secunde instalând același client Postgres cu apt la fiecare rulare; mutarea acesteia într-o imagine de bază CI mică alături de Node a însemnat că fragmentele ar putea începe gata de rulare. Ulterior, echipa a adăugat anteturi native de construcție la imagine, după ce a descoperit că descărcarea lor în timpul configurării se poate bloca ocazional.
De ce a rezonat
Postarea a lovit dezvoltatorii: a ajuns pe prima pagină a Hacker News, strângând aproximativ 250 de puncte și aproximativ 280 de comentarii într-o zi. Reacția este ușor de explicat – experiența lui Linear numește un cost al dezvoltării asistate de AI cu care se confruntă majoritatea organizațiilor de inginerie abia acum. Agenții care generează solicitări de extragere în câteva minute încă așteaptă conductele de validare concepute pentru cadența umană, iar fiecare minut din această așteptare este multiplicat pentru fiecare agent care lucrează în paralel.
Lecția din reelaborarea lui Linear este că blocajul este mobil, dar numai prin acumularea neplăcută a multor remedieri mici - alergători mai rapidi, verificări de tip mai ieftine, reguli de scame la nivel de sintaxă, preluări limitate, verificări rezistente, imagini prefabricate - mai degrabă decât orice singur glonț de argint.
---
Rămâneți înaintea AIObțineți cele mai recente știri, analize și descoperiri despre AI - toate într-un singur loc.
Citiți mai multe știri AI →
