Линейный инженер Муфиз Амджад опубликовал подробный отчет о том, как компания переработала свой конвейер непрерывной интеграции после того, как агенты ИИ-кодирования превратили CI в ее худшее узкое место — сократив время ожидания запроса на включение с более чем шести минут до чуть более пяти, в то время как ее наборы тестов увеличились почти в четыре раза с начала года.

Пост, опубликованный в инженерном блоге Linear 21 сентября, начался, как это часто бывает, с краткого указания сверху. Ранее в этом году Амджад открыл Linear и обнаружил, что Туомас, технический директор компании, поручил ему задачу под названием «Затраты на CI высоки» — и попросил его ускорить CI, пока он этим занимается. Дополнительную информацию об этой истории можно найти в нашем постоянном освещении об отрасли искусственного интеллекта.

Когда агенты опережают проверку

Проблема структурная, а не случайная. «Агенты значительно ускорили доставку кода, — пишет Амджад, — но проверка этих изменений не идет с той же скоростью». Каждый запрос на включение по-прежнему должен проходить через CI, поэтому по мере ускорения разработки CI становится узким местом, что приводит к росту затрат на инфраструктуру и заставляет разработчиков и их агентов дольше ждать обратной связи.

Линейный, оптимизированный для двух показателей: как долго PR ожидает CI и сколько времени он потребляет. Результаты после нескольких месяцев работы: несмотря на то, что наборы тестов увеличились почти в четыре раза с января, время ожидания запроса на включение сократилось с более чем шести минут до чуть более пяти, а время выполнения одного теста сократилось примерно вдвое.

Работа в целом разделилась на четыре категории: модернизация инфраструктуры и инструментов, оптимизация задач, которые управляют другой работой, сокращение количества повторных настроек и повышение эффективности выполнения тестов. Кодовая база Linear в основном представляет собой TypeScript, но многие оптимизации применимы к различным языкам и цепочкам инструментов.

Более быстрые машины и собственный компилятор

Некоторые из первых достижений практически не требовали оптимизации самой CI. Перенос рабочих нагрузок с GitHub Actions на сторонние программы с более быстрыми процессорами, более производительным хранилищем и улучшенной инфраструктурой кэша окупился сразу: при аналогичном сравнении двух дней по обе стороны от перехода задания выполнялись в среднем на 34% быстрее, а некоторые рабочие нагрузки, такие как `tsc`, упали на 52%.

Модернизация набора инструментов усугубила победу. Переход на `tsgo`, собственный компилятор TypeScript, сократил еженедельную медиану проверки типов на 73% — достаточно много, чтобы полностью устранить узкое место в проверке типов.

Линтинг без графа типов

Линтинг был еще одной ранней целью. Несколько пользовательских правил ESLint Linear зависели от информации о типе TypeScript, что заставляло каждый запуск проверки строить полный граф типов перед их оценкой, что делало проверку одним из наиболее ресурсоемких заданий CI.

Команда переписала правила, чтобы использовать статический анализ абстрактного синтаксического дерева, определяя функциональные конструкции и защитные шаблоны без какой-либо информации о типе. Это позволило ESLint полностью отказаться от TypeScript, сократив время проверки API на 68% и время проверки всего репозитория на 55%, при этом существенно сократившись использование памяти. Это также облегчило последующий переход на Oxlint, что еще больше сократило количество минут, затрачиваемых CI на анализ.

Сокращение критического пути

Благодаря ускорению отдельных проверок компания Linear уменьшила масштаб и рассматривала CI как систему. Это привлекло внимание к небольшим задачам, стоящим впереди всего остального — обнаружению изменений пути и проверкам кеша результатов тестов, которые осуществляются на уровне задания, а это означает, что ни один из восьми тестовых сегментов API не может начаться, пока они не завершатся.

Исправления были детальными, но аддитивными. Ограничение глубины выборки позволило самым медленным воротам сократить время с 94 секунд до 20. Полное удаление проверки из заданий, которым никогда не требовалось работающее дерево, сократило это время с 27 секунд до 7. Разреженная проверка без больших двоичных объектов с ограниченной историей сэкономила еще 11 с лишним секунд для событий push и слияния в очереди. В целом средняя продолжительность задания по обнаружению изменений снизилась с 26 секунд до 8, p90 — с 31 до 12, а самое медленное выполнение — со 138 секунд до 37.

Надёжность оформления заказа тоже нуждалась в доработке: поскольку сторонние исполнители находятся за пределами сети GitHub и полагаются на прямое IP-соединение, периодическая деградация канала иногда останавливала выборку. В Linear заменено `actions/checkout` собственным составным действием, которое повторяет попытку с откатом, устанавливает `GIT_HTTP_LOW_SPEED_LIMIT` и `GIT_HTTP_LOW_SPEED_TIME`, чтобы зависшее соединение прерывалось примерно через 30 секунд, а не зависало, и использует кэш проверки, который хранит постоянное зеркало git на липком диске.

Одно тонкое исправление устранило потерю времени в очереди на слияние: маркеры кэша записывались как часть финальной проверки перед слиянием, поэтому PR мог оставаться в очереди даже после прохождения тестов. Перемещение этой записи в задание без шлюзования сократило путь слияния на 42 секунды для каждого запроса на извлечение API и записи в очереди слияния. В совокупности эти изменения сократили необходимые проверки API PR на промахи в кэше примерно на минуту, одновременно сократив количество запусков бегуна.

Меньше потерянных секунд на одно задание

Стоимость установки последней атакованной категории повторяется для каждого задания. Каждый фрагмент теста API тратил от 7 до 8 секунд на установку одного и того же клиента Postgres с apt при каждом запуске; перемещение его в небольшой базовый образ CI рядом с Node означало, что сегменты могут быть готовы к работе. Позже команда добавила в образ собственные заголовки сборки, обнаружив, что их загрузка во время установки иногда могла зависать.

Почему это вызвало резонанс

Пост задел разработчиков: он попал на первую страницу Hacker News, набрав около 250 баллов и около 280 комментариев за день. Реакцию легко объяснить: опыт Linear указывает на стоимость разработки с использованием ИИ, с которой большинство инженерных организаций сталкиваются только сейчас. Агенты, генерирующие запросы на включение за считанные минуты, по-прежнему ждут конвейеров проверки, рассчитанных на частоту работы человека, и каждая минута этого ожидания умножается на каждого агента, работающего параллельно.

Урок переделки Linear заключается в том, что узкое место можно устранить, но только за счет некрасивого накопления множества мелких исправлений — более быстрых программ, более дешевых проверок типов, правил проверки на уровне синтаксиса, ограниченной выборки, отказоустойчивых проверок, готовых изображений — а не какой-либо одной серебряной пули.

---

Будьте впереди ИИ

Получайте последние новости, анализ и открытия в области искусственного интеллекта — все в одном месте.

Подробнее новости AI →