Linear halverte runner-tiden per test mens testsuiten nesten firedoblet seg

Tidlig i år åpnet Mufeez Amjad Linear og fant en sak teknisk direktør Tuomas hadde tildelt ham, med tittelen «CI costs are high». Han skulle gjøre CI raskere samtidig. Siden den gang har testsuitene nesten firedoblet seg, og agenter skriver nå flertallet av testene i kodebasen, mens ventetiden på en pull request har falt fra over 6 minutter til drøyt 5 og runner-tiden per test er omtrent halvert.

Infrastrukturen ga de første gevinstene nesten gratis. Å flytte arbeidslastene fra GitHub Actions til tredjeparts-runnere med raskere CPU-er ga 34 prosent kortere jobber i snitt, og tsc falt 52 prosent. Byttet til tsgo, den native TypeScript-kompilatoren, kuttet ukesmedianen for tsc-sjekken med 73 prosent. Da Linear skrev om sine egne lint-regler til å lese syntakstreet i stedet for å bygge hele typegrafen, falt API-lintingen 68 prosent og lintingen av hele repoet 55 prosent.

De største tallene kom likevel fra oppryddingen rundt selve testene. Sju små sjekker som hver startet sin egen runner ble slått sammen til to jobber, noe som etter junitallene sparte rundt 87 000 runner-minutter i måneden, eller 11,8 prosent av forbruket. Å la trygge testfiler dele modulregister med «isolate: false» var enkeltendringen som betydde mest: den tregeste sharden falt fra 300-379 sekunder til rundt 195, og samlet runner-tid for API-shardene gikk fra 32,8 til 22 minutter per kjøring. Linear skriver at det også var endringen med størst korrekthetsrisiko, og at agent-skillene deres måtte oppdateres slik at genererte tester følger de samme begrensningene.

Hva bør du gjøre?

1. Mål hvor lenge en pull request venter, ikke bare hvor lenge testene tar. Linear optimaliserte mot begge, og de to peker ikke alltid samme vei.
2. Se på småjobbene som kjører før alt annet. Å kappe fetch-dybden tok den tregeste portvakt-jobben fra 94 til 20 sekunder, og å fjerne checkout helt der arbeidstreet ikke trengs tok 27 sekunder ned til 7.
3. Etterprøv om cachen faktisk lønner seg. Linear fant at et treff på node_modules-cachen tok rundt 28 sekunder å gjenopprette, mot omtrent 7,5 sekunder for en installasjon begrenset til pakken jobben trenger.