Назад
AI-кодинг зробив CI вузьким місцем — як Linear переробив свій конвеєр
SiTech AI Team2 წთ. საკითხავი

AI-кодинг зробив CI вузьким місцем — як Linear переробив свій конвеєр

Linear розповіла, як переробила конвеєр CI: набір тестів зріс майже вчетверо, а час очікування pull request скоротився з понад шести хвилин до трохи більше п'яти.

Linear опублікувала опис того, як переробила конвеєр безперервної інтеграції (CI) після того, як AI-агенти настільки прискорили випуск коду, що перевірка змін стала найповільнішим етапом. Публікацію в блозі Now від 21 вересня підписав Муфіз Амджад (Mufeez Amjad); все почалося із завдання від CTO Туомаса «CI costs are high».

Чому CI став вузьким місцем

Агенти пишуть і випускають код значно швидше, але перевірка не встигає: кожен pull request усе одно проходить через CI, тож витрати зростають і зворотний зв'язок затримується. Linear працювала над двома показниками: часом очікування pull request і машинним часом на тест. Попри зростання набору тестів майже вчетверо, час очікування впав з понад шести хвилин до трохи більше п'яти, а машинний час на тест — приблизно вдвічі.

Графік: зростання набору тестів і скорочення машинного часу на тест

Швидша інфраструктура та лінтер

Перехід з GitHub Actions на сторонні runner'и прискорив завдання в середньому на 34%, а перевірку типів tsc — на 52%. Перехід на tsgo, нативний компілятор TypeScript, скоротив тижневу медіану перевірки типів на 73%. Власні правила лінтера, що залежали від інформації про типи, переписали на статичний аналіз синтаксичного дерева: ESLint відмовився від TypeScript, час лінту API впав на 68%, а лінту всього репозиторію — на 55%.

Критичний шлях і повторювана підготовка

Обмеження глибини checkout скоротило найповільніше зі службових завдань з 94 до 20 секунд, а медіана завдання визначення змін упала з 26 до 8 секунд. Перенесення запису кеш-маркера з шляху злиття заощадило 42 секунди на кожен API pull request.

Робочий процес test-api до і після: 4 хв 57 с проти 3 хв 14 с

Далі скоротили повторювану підготовку: pnpm install обмежили лише пакетом API (з 44-73 до 16-18 секунд), а час підготовки на шард зменшився зі 110-140 до 67-73 секунд. Об'єднання семи коротких перевірок у два завдання заощадило близько 87 000 runner-хвилин на місяць (11,8% усього споживання CI), а перехід з чотирьох шардів на вісім зробив критичне завдання приблизно на 19% швидшим і дешевшим.

Виконання тестів і підсумок

Найбільший одноразовий виграш дав opt-in проєкт Vitest із вимкненою ізоляцією: близько 17% місячної економії, найповільніший шард — з 300-379 до приблизно 195 секунд, а машинний час API-шардів — з 32,8 до 22 хвилин на запуск. Це була найризикованіша для коректності зміна. За оцінкою Linear, без цієї роботи сьогоднішній набір тестів тривав би близько 11 хвилин — майже вдвічі довше, ніж зараз; щотижня додається близько 2000 тестів, тож робота триває.

SSiTech

SiTech — веброзробка з підтримкою AI

Створюємо швидкі та сучасні сайти й інтегруємо AI у бізнес-процеси. Маєте проєкт чи запитання? Із задоволенням допоможемо.