Linear переработала CI-пайплайны, чтобы не отставать от скорости генерации кода ИИ
Hacker News · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Компания Linear оптимизировала инфраструктуру непрерывной интеграции, сократив время ожидания PR с 6 до 5 минут при четырехкратном росте тестовой базы. Ключевыми шагами стали миграция на быстрые раннеры, отказ от кэширования там, где пересборка быстрее, и агрессивное параллелизация тестов.
Ценность: По мере того как ИИ-агенты ускоряют написание кода, система проверки (CI) становится узким местом. Опыт Linear демонстрирует, что без глубокой оптимизации инфраструктуры стоимость и задержки растут непропорционально скорости разработки.
В начале года CTO Linear Туомас поставил перед командой задачу снизить затраты на CI и ускорить процесс. Причиной стало то, что ИИ-агенты стали выпускать код экспоненциально быстрее, но валидация изменений не поспевала за этим темпом. Каждый пулл-реквест (PR) должен проходить через CI, что превращало систему в бутылочное горлышко: инфраструктурные расходы росли, а разработчики и агенты дольше ждали обратной связи. Несмотря на то что тестовые наборы почти утроились с начала года, компании удалось сократить время ожидания PR с более чем 6 минут до чуть более 5, а время работы раннера на один тест — примерно вдвое.
Оптимизация началась с модернизации инфраструктуры. Перенос рабочих нагрузок с GitHub Actions на сторонние раннеры с более быстрыми CPU и улучшенным кэшированием позволил ускорить выполнение задач в среднем на 34%. Отдельно компания перешла на нативный компилятор TypeScript (tsgo), что сократило медианное время проверки типов на 73% в неделю. Это полностью сняло нагрузку с этапа типизации. Также была переписана система линтинга: вместо использования полной графа типов, которая требовала огромного объема памяти, правила были адаптированы под статический анализ абстрактного синтаксического дерева. Это позволило отказаться от TypeScript в процессе линтинга, сократив время проверки API на 68%.
Важным шагом стало оптимизирование «гейтов» — небольших задач, которые блокируют запуск остальных. Например, проверка измененных путей теперь требует только частичного клонирования репозитория (sparse checkout), что сократило время с 94 до 20 секунд. Для устойчивости к сетевым сбоям на сторонних раннерах команда заменила стандартный checkout на собственный композитный экшен с ретраями и лимитами скорости, предотвращающий зависания.
Команда также пересмотрела подход к установке зависимостей. Вместо установки всего монорепозитория (pnpm workspace) для каждой задачи, зависимости устанавливались только для нужного пакета. Это сократило время установки с 44–73 секунд до 16–18 секунд. Интересным открыжением стало то, что кэширование node_modules оказалось менее эффективным, чем пересборка: восстановление кэша занимало около 28 секунд, тогда как фильтрационная установка — всего 7,5 секунды. В результате время настройки каждого шарда сократилось на 44%.
Наконец, была оптимизирована сама загрузка тестов. Разработчики разбили крупные файлы тестов на более мелкие, чтобы Vitest мог лучше распределять нагрузку, и увеличили количество шардов с четырех до восьми. Наибольший эффект дало отключение изоляции модулей для безопасных файлов (isolate: false), что позволило разделять реестр модулей внутри воркера. Это стало самым крупным одиночным улучшением, сэкономившим около 17% месячных ресурсов. Время самого медленного шарда упало с 300–379 секунд до примерно 195 секунд.
По оценкам компании, без этих оптимизаций текущий тестовый набор занял бы около 11 минут, что вдвое больше нынешнего времени ожидания. Linear продолжает добавлять около 2000 тестов в неделю, поэтому поддержка высокой скорости CI остается постоянным процессом, где новые решения применяются к возникающим узким местам.