Монорепозиторий перед продакшеном: чек-лист без ложного зелёного

В монорепозитории зелёный CI сам по себе не подтверждает безопасность релиза: изменение общей библиотеки может затронуть несколько приложений, а проверка только изменённого пакета не заметит проблему в зависимом проекте. Ниже — чек-лист для JavaScript/TypeScript-монорепозитория на pnpm 9.x и Turborepo 2.x: что проверить перед продакшеном и где ускорение сборки превращается в риск.

Сначала зафиксируйте границы проверки

Этот разбор — о подготовке изменений к релизу, а не о выборе монорепозитория или настройке CI с нуля. Примеры относятся к проектам с рабочими пространствами pnpm и задачами, описанными для Turborepo 2.x. Если у вас другие версии или инструменты, сверяйте детали с их документацией: названия команд и поведение кэша могут отличаться.

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

Чек-лист перед выпуском

1. Убедитесь, что CI использует зафиксированный набор зависимостей. Установка в CI должна проверять lockfile, а не молча обновлять его. Сверьте версии Node.js и пакетного менеджера в локальной среде и CI. Проверьте результат на чистом запуске: если сборка работает только благодаря старым файлам или глобально установленному пакету, это не воспроизводимая проверка.
2. Проверьте граф задач и зависимостей. Для каждой сборки и проверки должно быть понятно, какие проекты запускаются раньше и от каких пакетов зависит результат. Изменение общей библиотеки должно вести к проверке потребителей, а не только самой библиотеки. Проверка: внесите безвредное изменение в общий пакет в тестовой ветке и убедитесь, что CI включает зависимые приложения.
3. Убедитесь, что тесты проверяют публикуемый результат. Если приложение использует собранный пакет, тестируйте не только исходники библиотеки, но и сценарий сборки, которым пользуется потребитель. Проверьте экспорты, пути к файлам и наличие нужных артефактов. Успешный тест исходного кода не доказывает, что пакет можно собрать и подключить.
4. Проверьте фильтрацию проверок. Если CI запускает только задачи для изменённых проектов, убедитесь, что он учитывает обратные зависимости: потребителей изменённого пакета. Отдельно проверьте изменения конфигурации, общих скриптов и файлов, влияющих на весь репозиторий. Для таких изменений безопаснее запускать более широкий набор проверок.
5. Сделайте кэш проверяемым. Убедитесь, что результат задачи зависит от всех входных данных: исходников, lockfile, конфигурации сборки и значимых переменных окружения. Если изменение этих данных не меняет ключ кэша, CI может использовать результат предыдущего запуска. Проверка: измените в тестовой ветке один вход, который должен влиять на сборку, и убедитесь, что задача выполняется заново.
6. Разделите артефакты и релизы. Определите, какие приложения выпускаются независимо, а какие требуют согласованного обновления общих пакетов. Проверьте, что релизный процесс берёт артефакт именно из проверенной сборки, а не собирает его заново с потенциально иными зависимостями или настройками.
7. Пройдите сценарий отката. Зафиксируйте, как остановить выпуск и вернуть предыдущую версию приложения. Если релиз общей библиотеки меняет совместимость, одного отката приложения может быть недостаточно. Проверка: команда должна назвать владельца решения, шаги возврата и способ убедиться, что система восстановилась.

Зелёный статус полезен только тогда, когда команда может ответить на вопрос: какие именно проекты и зависимости он проверил?

Три стратегии CI: скорость против уверенности

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

Как выбрать режим

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

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

Что чаще всего ломает уверенность в CI

• Неполный граф зависимостей. Пакет используется приложением, но связь не отражена в манифесте или настройках задач. Фильтр считает приложение незатронутым и пропускает его сборку.
• Разные версии инструментов. Локально проект собирается одной версией Node.js или пакетного менеджера, а CI — другой. Зафиксируйте ожидаемые версии и проверяйте их при запуске.
• Слишком широкое доверие к кэшу. Задача возвращает старый результат, хотя изменились важные входные данные. Проверьте, какие файлы и переменные учитывает кэш, и сравните поведение с запуском без него.
• Проверка только исходников. Тесты проходят, но пакет не собирается или не содержит нужные файлы. Добавьте проверку сценария сборки и потребления собранного артефакта.
• Релиз вне проверенного процесса. Артефакт пересобирают вручную или выпускают пакет, которого не было в успешно проверенном наборе. Свяжите выпуск с конкретным результатом CI и версией исходников.

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

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

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

После этого измеряйте две вещи: время от отправки изменения до результата обязательных проверок и число повторных запусков из-за неполного или неверного результата. Документацию по рабочим пространствам pnpm и конфигурации задач Turborepo сверяйте с версиями, установленными в репозитории.