AI-კოდირებამ CI ბარიერად აქცია — როგორ გადაამუშავა Linear-მა საკუთარი პროცესი

Linear-მა აღწერა, თუ როგორ გადაამუშავა უწყვეტი ინტეგრაციის (CI) პროცესი მას შემდეგ, რაც AI-აგენტებმა კოდის გამოშვება იმდენად დააჩქარეს, რომ ცვლილებების შემოწმება ყველაზე ნელი ეტაპი გახდა. 21 სექტემბერს Now ბლოგზე გამოქვეყნებული სტატია Mufeez Amjad-ს ეკუთვნის; საქმე CTO Tuomas-ის მიერ მიცემული ამოცანით დაიწყო — სათაურით „CI costs are high“.

რატომ გახდა CI ბარიერი

აგენტები კოდს ბევრად სწრაფად წერენ და უშვებენ, შემოწმება კი იმავე ტემპს ვერ მიჰყვება: ყოველი pull request მაინც CI-ს გადის, ამიტომ ხარჯები იზრდება და უკუკავშირიც ჭიანურდება. Linear-მა ორ მაჩვენებელზე იმუშავა: pull request-ის ლოდინი და ერთ ტესტის runner-დრო. შედეგად, ტესტების თითქმის ოთხმაგი ზრდის პირობებში ლოდინი 6 წუთზე მეტიდან 5 წუთამდე შემცირდა, runner-დრო კი განახევრდა.

სწრაფი ინფრასტრუქტურა და ლინტი

GitHub Actions-იდან მესამე მხარის runner-ებზე გადასვლამ სამუშაოები საშუალოდ 34%-ით დააჩქარა, ტიპების შემოწმება კი 52%-ით; tsgo-ზე გადასვლამ კვირის მედიანური შემოწმება 73%-ით შეამცირა. ტიპებზე დამოკიდებული ლინტის წესები სინტაქსური ხის სტატიკურ ანალიზზე გადაწერეს — ESLint-მა TypeScript-ზე დამოკიდებულება მოიშორა, API-ის ლინტი 68%-ით, მთელი რეპოზიტორიისა კი 55%-ით დაჩქარდა.

კრიტიკული გზა და მომზადება

პატარა საკონტროლო შემოწმებებზე გადასვლამ შედეგი მოიტანა: checkout-ის სიღრმის შეზღუდვამ ყველაზე ნელი მათგანი 94 წამიდან 20-მდე დაიყვანა, სამუშაო ხის გარეშე დარჩენილებში კი checkout საერთოდ მოიხსნა (27-დან 7 წამამდე); ცვლილებების აღმომჩენი სამუშაოს მედიანა 26 წამიდან 8-მდე დაეცა. cache marker-ის გაერთიანების გზიდან გადატანამ ყოველ API pull request-ს 42 წამი მოაკლო.

განმეორებადი მომზადებაც შემცირდა: pnpm install მხოლოდ API-ის პაკეტზე შემოიფარგლა (44-73 წამიდან 16-18-მდე), shard-ზე მომზადების დრო კი 110-140 წამიდან 67-73 წამამდე დაეცა. შვიდი მოკლე შემოწმების ორ სამუშაოში გაერთიანებამ თვეში ~87 000 runner-წუთი, მთელი CI-ის მოხმარების 11.8%, დაზოგა; shard-ების რაოდენობა ოთხიდან რვამდე გაიზარდა და კრიტიკული სამუშაო ~19%-ით დაჩქარდა და გაიაფდა.

ტესტების შესრულება და შედეგი

ყველაზე დიდი მოგება გამორთული იზოლაციის opt-in Vitest პროექტმა მოიტანა — თვიური დანაზოგი ~17%, ყველაზე ნელი shard 300-379 წამიდან ~195-მდე, API-ის shard-ების runner-დრო კი გაშვებაზე 32.8-დან 22 წუთამდე. სისწორისთვის ეს ყველაზე რისკიანი ცვლილება იყო. Linear-ის შეფასებით, ამ სამუშაოს გარეშე დღევანდელი ტესტები ~11 წუთს მოითხოვდა — თითქმის ორჯერ მეტს, ვიდრე ახლა; კვირაში ~2000 ტესტი ემატება, ამიტომ მუშაობა გრძელდება.