Удалённый кэш сборки для монорепо без привязки к провайдеру

Почему сборки в монорепо замедляются

Монорепо сначала кажется быстрым. Вы храните приложения, общие пакеты, тесты и код деплоя в одном месте, и повседневная работа упрощается.

Потом репозиторий растёт. Команда тоже растёт. Одно небольшое изменение начинает запускать слишком много задач.

Обычно так происходит потому, что инструменты сборки и CI действуют осторожно. Когда меняется общий пакет, они пересобирают всё, что может на него зависеть. Если граф зависимостей неопрятный или правила сборки слишком широкие, маленький правка в одной папке может запустить веб‑сборки, API‑тесты, проверки мобильных приложений и создание образов, которые вовсе не нужно было выполнять.

Ветки усугубляют ситуацию. Разработчик открывает pull request, и CI запускает полный пайплайн. Потом он пушит исправление опечатки, и CI повторяет ту же дорогую работу. Другая ветка затрагивает похожие файлы — и система делает всё снова. Команды тратят часы на компиляцию кода, который уже компилировали вчера.

Пустые раннеры добавляют ещё стоимость. Многие CI‑платформы стартуют каждую задачу на чистой машине. Это выглядит аккуратно, но такая машина ничего не помнит: у неё нет локальных артефактов сборки, тёплого кеша зависимостей и результатов тестов с предыдущих прогонов. Каждая сборка стартует «холодной», скачивает одни и те же входы и пересобирает одни и те же таргеты.

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

Команда может мириться с десятиминутной сборкой. Тридцатипятиминутная сборка меняет поведение людей. Обычно именно в этот момент имеет смысл задуматься о общем удалённом кэше. Не потому, что это выглядит продвинуто, а потому что многочисленная лишняя работа начинает складываться в заметную потерю времени.

Что реально экономит кэш

Кэш экономит время, сохраняя уже выполненную работу. В большом репо одно небольшое изменение не должно заставлять заново запускать сборку каждого пакета, теста и бандла. Удалённый кэш даёт всей команде переиспользовать результаты, а не только тому, кто собрал их первым.

Большинство кэшей хранит три вещи: выходы сборки, результаты задач и хеш, который доказывает, что эти результаты безопасно переиспользовать. Хеш — самый важный: он фиксирует входы для задачи, такие как исходники, lockfiles, настройки компилятора, значения окружения и сама команда.

Если входы совпадают, инструмент сборки подтягивает старый результат и пропускает задачу. Если что‑то изменилось — задача выполняется снова. Это нормально: промах кэша — не ошибка, а сигнальный факт, что путь безопаснее выполнить заново.

На практике кэш может хранить скомпилированные файлы, сгенерированный код, результаты тестов для неизменённых пакетов и метаданные, которые сопоставляют каждую задачу с её точным входным хешем.

Это отличается и от контроля версий, и от хранилищ релизов. Git держит код и историю. Ваш реестр пакетов или стор хранят релизы, которые вы публикуете целенаправленно. Кэш стоит рядом с ними и хранит временные данные сборки, которые всегда можно восстановить.

Это разделение важно. Если вы удалите кэш, пайплайн продолжит работать — просто несколько прогонов будут медленнее, пока кэш не «прогреется» снова. Если смешать кэш с релизными артефактами, уборка быстро превратится в хаос.

Команды также получают лучшие результаты, когда изучают промахи кэша вместо того, чтобы бояться их. Сравните тёплые сборки с холодными. Посмотрите, какие задачи чаще всего промахиваются. Внезапное падение процента попаданий обычно указывает на шумные входы, нестабильные настройки окружения или задачи, которые генерируют разные выходы каждый раз.

Простой пример ясно показывает идею. Разработчик правит один UI‑пакет, открывает PR, и CI переиспользует неизменённые результаты сборки и тестов для двадцати других пакетов. Сборка всё равно проверяет корректность — она просто перестаёт платить полную цену за каждый прогон.

Что вы должны контролировать

Скорость важна, но контроль важнее. Удалённый кэш должен сокращать время сборки, не привязывая команду к одному CI‑провайдеру, модели биллинга или скрытому формату.

Начните с хранения, которое можно перенести. Простое объектное хранилище обычно самое безопасное, потому что вы сможете указать другой раннер, другой CI‑сервис или другой регион на те же данные позже. Если вы когда‑то смените провайдера, вы хотите переносить бакеты и учётные данные, а не перепроектировать весь пайплайн.

Держите правила доступа простыми. Дайте раннерам один ясный способ читать записи кэша и один ясный способ их записывать. Если нужно — разделите права на чтение и запись, но избегайте лабиринта токенов, сервисных аккаунтов и исключений. Сложный авторизационный слой ломается в самый неподходящий момент, и командa начинает винить кэш, когда истинная причина — дрейф доступа.

Ретеншн тоже должен быть под вашим контролем. Старые данные кэша быстро накапливаются в бурном монорепо, особенно когда ветки, версии инструментов и таргеты создают свои записи. Настройте сроки жизни, лимиты размеров и задачи очистки, чтобы расходы оставались предсказуемыми.

Полезно прописать четыре базовых правила: кто может читать кэш, кто может публиковать новые записи, как строятся ключи кэша и когда раннеры должны пропускать запись. Короткий ранбук экономит время при приходе нового инженера или при резком падении hit rate.

Будьте осторожны с «удобными» функциями от CI‑вендоров. Некоторые из них хороши, другие работают только внутри одного хостинга раннеров и тихо вводят вас в залоченное положение. Если ключи кэша, метаданные или правила восстановления имеют смысл только внутри одного сервиса — это не ваша собственность.

Хороший тест прост: сможет ли команда перенести этот кэш на другой CI за неделю без изменения локальной сборки? Если ответ «нет», значит настройка слишком сильно завязана на одного провайдера.

Конфигурация, которая остаётся переносимой

Самая чистая схема держит логику кэша в инструменте сборки, а не внутри хостированного CI. Инструмент должен решать, когда работа совпадает с прошлым прогоном, по хешу входов и ожидаемых выходов. Обычно это включает исходники, конфиги, lockfiles, флаги сборки и иногда версию инструмента. Если хеш совпадает — раннер может переиспользовать старый результат вместо пересборки.

На высоком уровне поток прост: инструмент сборки создаёт хеш для каждой задачи. Раннер проверяет совместное хранилище на наличие этого хеша. Если он находится — восстанавливает сохранённый вывод. Если нет — выполняет задачу и загружает результат.

Такая схема скучна в лучшем смысле слова. Вы можете сменить CI‑провайдера позже, потому что формат кэша и хранилище остаются под вашим контролем.

Храните файлы кэша в объектном хранилище под вашим управлением: S3‑совместимый бакет, Google Cloud Storage, MinIO или другой простой blob‑стор. Сохраняйте выходы как zip‑файлы или артефакты по путям, основанным на хеше. Объектное хранилище обычно дешёвое, его легко копировать и проще переместить, чем сервис‑кэш провайдера.

Если нескольким раннерам нужен общий доступ, добавьте тонкий слой авторизации. Во многих командах CI может выдавать временные креденшалы только для одного бакета. Если это непрактично, тонкий прокси может подписывать запросы на загрузку и скачивание. Держите права узкими: раннеру для чтения и записи кэша не нужен доступ к базам данных, репозиторию или остальной инфраструктуре.

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

Очищайте по расписанию. Удаляйте записи, к которым никто не обращался несколько недель, храните свежие данные веток и удаляйте слишком большие артефакты, которые дороже хранить, чем пересобрать. Если делать это с первого дня, кэш остаётся быстрым, дешёвым и переносимым.

Как развернуть без драмы

Делайте rollout маленькими шагами. Если переключить всё репо сразу, вы не поймёте, откуда взялся прирост скорости: от кэша, от изменения конфигурации или от простой удачи.

Начните с измерения одного медленного задания до изменений. Фронтенд‑сборки часто хороший первый кандидат: они частые, занимают время и обычно зависят от понятного набора входов — исходников и lockfiles. Ведите базу с холодным временем сборки, повторным временем и частотой запусков этого задания в CI в день.

Относитесь к первой фазе как к эксперименту, а не миграции. Выберите один пакет или приложение, включите удалённое чтение, а запись оставьте выключенной. Это позволит проверить, что восстановленные результаты корректны, не засоряя кэш плохими записями.

Через несколько дней проверьте цифры. Если задание восстанавливается корректно и hit rate стабилен, разрешите запись из одного доверенного источника, обычно CI в ветке main. Это предотвратит попадание незавершённых или грязных артефактов из локалей разработчиков.

Rollout может оставаться простым. Измеряйте одно медленное задание неделю. Включите только чтение для него. Затем разрешите запись из CI, когда результаты выглядят надёжными. Потом добавляйте следующий пакет или приложение.

Особо чётко пропишите правило: когда обходить кэш? Изменение lockfile, апгрейд компилятора, изменение переменной окружения или скрипта сборки могут сделать старые записи бесполезными. Если никто не знает, когда нужно пропустить кэш, команда потратит часы на поиск странных багов.

Небольшая команда на self‑hosted GitLab‑раннерах, например, может протестировать это на одном приложении Next.js и хранить артефакты в объектном хранилище. Когда приложение надёжно восстанавливается и CI ускоряется, можно добавлять общие пакеты по одному. Медленный rollout обычно лучше, чем большой запуск.

Реалистичный пример команды

Представьте семь человек в продуктовой команде с веб‑приложением, API и общими пакетами в одном репо. Структура простая: apps/web, apps/api и несколько общих папок для UI‑компонентов, типов и утилит. Шеринг кода удобен, но времена сборки растут, как только каждый pull request попадает в один и тот же пайплайн.

Их первая боль очевидна. Дизайнер меняет стиль кнопки в общем UI‑пакете — и сборка API запускается снова без причины. Тут на помощь приходит удалённый кэш: он хранит результаты отдельно по таргетам, так что веб‑приложение пересобирает то, что изменилось, а бэкенд‑джоб переиспользует предыдущие результаты.

Команда держит кэш в объектном хранилище под своим управлением, а не привязывается к одному CI‑вендору. CI по‑прежнему выполняет задания, но выводы живут в бакете, который можно переместить, скопировать или проинспектировать. Если позднее сменят раннеры, кэш и логика сборки останутся.

Ветки фич получают бонус. Разработчик ветвится от main, меняет один экран и пушит коммит. Ветка может подтянуть кэшированные результаты из последней успешной сборки main для неизменённых таргетов. Это экономит много работы, особенно для тестов и компиляций, зависящих от общих пакетов, но фактически не изменившихся.

Команда также запускает ночную задачу, которая собирает самые распространённые таргеты из main и обновляет кэш перед утренним пиком. Звучит просто, но это сильно сокращает ожидание первых PR утром.

Они следят за промахами. После обновления зависимости hit rate часто падает, потому что изменились lockfiles, версии инструментов или настройки окружения. Тогда команда проверяет: промах реальный или ключ кэша слишком широкий. Хороший кэш должен пропускать работу там, где это безопасно, а не скрывать проблемы.

Эта схема не кажется вычурной. Она просто не даёт CSS‑правке превратиться в полную пересборку бэкенда.

Ошибки, которые портят результат кэша

Удалённый кэш работает только если ключ кэша соответствует реальности. Если хеш пропускает важный вход, вы получите худшее сочетание: медленные сборки в одних прогонах и неправильные выходы в других.

Обычная ошибка — хешировать исходники, пропуская lockfiles, версии компилятора или версию инструмента сборки. Тогда два разработчика выполняют по‑видимому одну и ту же сборку с разными зависимостями, но попадают в один и тот же кэш. Сборка проходит быстро, но результат может быть неверным. Включайте всё, что меняет результат: lockfiles, версию компилятора, флаги сборки, переменные окружения и сгенерированные схемы.

Совместная запись создаёт другую проблему. Если каждая ветка пишет в один и тот же кэш, недоверенный код может его «отравить». Сломанная ветка загружает артефакты, которые выглядят корректно, а потом переиспользуются в main. Пусть ветки фич читают общий кэш, а записывают только доверенные задания.

Ещё одна проблема — смешение тестовых артефактов с выходами сборки. Тесты часто зависят от времени, случайных данных, snapshot'ов, локальных портов или состояния сервисов. Выходы сборки должны быть повторяемыми. Держите эти два типа данных раздельно и назначьте им разные правила очистки.

Затраты на хранение тоже нарастают, если команды хранят старые записи навсегда. Большая часть данных кэша быстро «остывает», но вы продолжаете платить за их хранение. Настройте правила удаления по возрасту и, если нужно, по количеству попаданий: если запись не использовалась несколько недель — удаляйте её.

Самая расточительная привычка — стирать весь кэш после одной странной ошибки. Это скрывает реальную проблему и заставляет всех пересобирать с нуля. Если один таргет ведёт себя странно, удалите только его запись и проверьте входы.

Пара простых правил помогает сильно: хешируйте lockfiles, версии компилятора, флаги сборки и сгенерированные входы; пусть доверенные ветки пишут, а остальные только читают; храните тестовые данные отдельно; целенаправленно удаляйте старые записи.

Когда сборки начинают вести себя рандомно, команды часто винят кэш. Чаще всего настоящая причина — неполные входы.

Быстрая проверка перед тем, как доверять

Перед тем как полагаться на удалённый кэш, протестируйте его как любую другую зависимость сборки. Быстрые демо могут скрывать плохие правила кэша, раздутые артефакты или промахи, которые проявятся только при росте команды.

Начните с повторяемости. Два прогона CI на одном и том же коммите должны показывать примерно одинаковую картину попаданий в кэш, если используются те же lockfiles, образ, окружение и флаги сборки. Если в одном прогоне много попаданий, а в другом всё пересобирается — значит в ключи прокрались нестабильные входы.

Ещё один тест — небольшое изменение зависимости. Поднимите версию одного пакета и посмотрите, какие таргеты пересобираются. Затронутые модули должны промахнуться, а не связанные части репо — попадать в кэш. Если перестраивается весь граф — правила инвалидации слишком широкие. Если вообще ничего не перестроилось — они слишком свободные.

Время важнее процента попаданий. Попадание в кэш нужно только если восстановление быстрее пересборки. Тянуть большой артефакт из объектного хранилища, чтобы сэкономить пару секунд — не выигрыш.

Перед тем как считать настройку готовой, запустите один и тот же коммит дважды и сравните счётчики попаданий и промахов. Измените зависимость и подтвердите, что перестраиваются только связанные таргеты. Измерьте время восстановления, время распаковки и время пересборки рядом. Сравните ежемесячный счёт за хранение с количеством сэкономленных CI‑минут. И дайте разработчикам простой способ принудительно выполнить чистую сборку.

Это важнее, чем кажется. Когда тест падает только с кэшированными выходами, нужен простой «аварийный выход», например флаг no cache или простая переменная окружения. Если обход кэша требует пяти шагов, люди перестанут ему доверять.

Затраты тоже требуют жёсткого взгляда. Self‑hosted хранилище обычно дешёвое, но при росте репо ситуация может выйти из‑под контроля. Настройте правила хранения заранее. Если старые артефакты валяются бесконечно, объём растёт, а лишние данные никому не помогают.

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

Что делать дальше

Начните с малого на этой неделе. Выберите один рабочий поток, который часто запускается и отнимает больше всего времени — например сборки pull request'ов для основного приложения и пары общих пакетов. Протестируйте кэш на этом узком пути, а затем расширяйте, когда увидите реальные цифры.

Держите пробу простой. Зафиксируйте текущее время сборки за 10–20 прогонов. Сначала включите удалённое чтение, потом запись. Ведите логи с попаданиями и промахами. С первого дня задайте базовое правило ретенции.

Проба должна идти месяц, и за это время внимательно смотрите три числа: общее время сборки, процент попаданий и рост хранения. Общее время покажет, помогает ли это в реальной жизни. Hit rate — сохраняются ли ваши ключи стабильными. Рост хранения — становится ли система дешёвой или начинает собирать мусор.

Не привязывайте дизайн слишком плотно к одному CI‑вендору. Держите кэш в объектном хранилище под вашим контролем и логику кэша достаточно простой, чтобы другой раннер мог воспроизвести те же шаги. При переходе между CI‑сервисами ваше хранилище и формат кэша не должны требовать полной переработки.

Одно правило помогает: держите вычисления отдельно от хранения. CI‑джобы приходят и уходят. Ваш бакет, политика хранения и схема имён должны оставаться читаемыми и переносимыми.

Если первый месяц прошёл хорошо, расширяйтесь на второй рабочий поток, а не сразу на всё монорепо. Так плохие ключи, шумные записи и громоздкие артефакты проще заметить до того, как они распространятся.

Если хотите внешний обзор, Oleg Sotnikov (oleg.is) работает со стартапами и небольшими командами по CI, инфраструктуре и роли Fractional CTO. Короткий обзор дизайна кэша, настройки раннеров и плана хранения может найти дорогостоящие ошибки до того, как они превратятся в ежедневную боль.