Монорепа — это удобно.
Пока тебе не нужно внести глобальные изменения.
Обновить Angular, поменять сборщик, переехать на новый подход к архитектуре, провести массовую миграцию… Любой такой шаг превращался в мини-кризис: команды не понимали, кто тестирует, ревью висело неделями, а изменения иногда прилетали в прод, прежде чем их вообще кто-то посмотрел.
В итоге все боялись глобальных изменений и каждое обновление Angular превращалось в приключение.
Я решил это исправить. Через синхронизацию с лидами и ключевыми фронтенд-разработчиками мы сделали единый, прозрачный и предсказуемый процесс внесения глобальных изменений — теперь через него проходит каждое важное вмешательство в монорепу.
Эта статья — про то, зачем он нужен, как он построен и какие проблемы решает.
Когда стало понятно, что без процесса — никак
Монорепа живёт по своим правилам. В отличие от отдельных репозиториев, здесь глобальное изменение может:
сломать десятки проектов одновременно;
потребовать межкомандного тестирования;
привести к несовместимости версий виджетов на проде;
вызвать прямые финансовые убытки.
Когда процесса нет, происходит следующее:
RFC пишут кто как умеет и когда вспомнит;
ревью застревает, потому что непонятно, кто обязан смотреть;
тестирование теряется между задачами команд;
релизы выкатываются в разные дни, ломая совместимость;
нет ясности, кому эскалировать, если всё стопорится.
Мы пришли к очевидному выводу: глобальные изменения должны идти по формальному, прозрачному и единому маршруту.
Что считается «глобальным» изменением
Процесс обязателен для изменений, которые:
затрагивают всю монорепу;
могут сломать работу проектов;
требуют межкомандного тестирования;
несут риск убытков или деградаций.
Примеры:
обновление Angular или других ключевых пакетов;
переход на новый сборщик или архитектурный подход;
крупные миграции, затрагивающие MFE, shared-библиотеки, CI.
Не требуют процесса:
минорные патчи зависимостей;
небольшие конфигурационные правки;
добавление безопасных и популярных библиотек.
Для них достаточно MR с тегом дежурных по монорепе.
Почему мы ввели обязательный RFC и строгий шаблон
Раньше это выглядело так:
Разработчик обновляет общий модуль. Пайплайны зелёные и автотесты прошли — значит, всё хорошо, но в проде два проекта начинают падать в рантайме. Падают из-за того, что проблемная часть не была покрыта автотестами и данный кейс был упущен при прогоне тестов на стейджинге.
В итоге кто должен тестировать — неясно, плана отката нет, всё чинится в пожарном режиме.
Мы решили полностью прекратить такой хаос.
RFC — это не бюрократия, а инструмент, который обеспечивает:
единый формат для целей, рисков, плана и отката;
прозрачность для всех команд;
предсказуемость сроков;
документ, который можно поднять через полгода и понять контекст.
Мы сделали строгий шаблон RFC, где есть:
цель и проблема;
план действий;
затрагиваемые команды;
риски;
план отката;
альтернативы;
таймлайн;
список согласовавших.
И самое важное есть SLA на каждый статус задачи, чтобы инициативы доводились до конца в разумные сроки.
Полный процесс глобальных изменений
1. Инициатива
Статус задачи в Jira: To Do → Research / Tech Review
создаётся задача в Jira;
заполняется RFC по шаблону;
пост выкладывается в канал монорепы с тегами дежурных и лидов затронутых команд.
Задача: понять объём работ, риски и участников.
SLA: 3 рабочих дня на первичное ревью RFC.
2. Коммуникация с лид-командами и CTO
Статус задачи в Jira: In Progress
Отдельным постом сообщаем:
какое изменение готовится и зачем;
какие команды затронет;
когда планируется разработка;
какой объём тестирования потребуется.
Каждая команда даёт ответ, когда сможет взять тестирование.
SLA:
взять тестирование — до 10 рабочих дней;
завершить — до 15 рабочих дней.
3. Разработка
Статус задачи в Jira: In Progress
следуем плану из RFC;
фиксируем отклонения, найденные костыли и нюансы — чтобы контекст не потерять.
4. Код-ревью
Статус задачи в Jira: Code Review
MR прикладывается в тред RFC;
тегаются дежурные.
SLA:
ревью — 3 рабочих дня (до 5 дней при массовых правках).
5. Тестирование
Статус задачи в Jira: Ready for test → In testing
разработчик тегает лидов и прикладывает список того, что нужно проверить;
QA создают задачи у себя;
ответственный следит, чтобы тестирование реально началось.
Если что-то ломается:
либо фиксит инициатор;
либо, по договорённости, команда, чья зона ответственности пострадала.
После подтверждений всех команд задача переходит в «Ready for release».
6. Подготовка к релизу
Статус задачи в Jira: Ready for release
объявляем время деплоя;
назначаем ответственных за проверку виджетов (если необходимо);
рискованные релизы планируем в вечерний слот.
7. Релиз
Статус задачи в Jira: Release
Два сценария:
1) Изменение глобальное, но можно выкатывать по проектам
мержим в master;
выкатываем один проект для проверки;
сообщаем о релизе.
2) Изменение требует одновременной раскатки MFE (например, обновление мажорной версии Angular)
мержим в master;
тегаем ответственных;
запускаем деплой всех MFE;
после раскатки команды валидируют результат. Если что-то пошло не так — делаем откат.
8. После релиза
Статус задачи в Jira: Release → Close
публикуем итоговый пост: что изменилось, какие скрипты появились;
если была проблема — заводим дизастер, делаем постмортем и фиксируем action items.
Почему этот процесс — это ускорение, а не бюрократия
Он работает, потому что:
Все заранее знают когда будет MR, тестирование и релиз.
У всех есть понятные SLA и ожидания.
Ответственные фиксируются формально — не нужно устных договорённостей.
Команды могут планировать ресурсы заранее.
Любой разработчик может инициировать важное улучшение.
CTO подключается только при блокировках — а не на каждом шаге.
Мы получили:
меньше хаоса,
меньше неожиданностей,
больше прозрачности,
выше качество релизов.
И главное — глобальные изменения перестали быть стрессом. Они стали обычной частью инженерного процесса.
Наш шаблон RFC
Немного упрощённый для статьи
# RFC: [Название инициативы] Автор: [Имя, команда] Дата: [ДД.ММ.ГГГГ] Статус: Draft / In review / Approved Задача: Ссылка на задачу в Jira Тред: Ссылка на обсуждение RFC ## 1. Цель и проблема - Опиши, зачем нужны эти изменения. - Укажи текущие проблемы или ограничения. - Объясни, почему важно решать их именно сейчас. Например, устаревший Angular мешает использовать современные подходы разработки, возникают потенциальные трудности с наймом из-за legacy-фреймворка, риски безопасности и т.д. ## 2. План действий - Опиши шаги внедрения изменений. - Укажи инструменты и скрипты, которые будут использоваться. - Укажи примерную продолжительность каждого этапа. - Назначь ответственных за выполнение. - Для крупных изменений (например, переход на nx buildable libs) разбей процесс на фазы, которые можно тестировать и внедрять поэтапно. ## 3. Затрагиваемые команды - Перечисли команды, чьи зоны ответственности будут затронуты. - Укажи, как именно их код или процессы будут затронуты. - Отметь, нужно ли их участие в код-ревью и тестировании. ## 4. Риски - Опиши возможные риски: - технические (например, несовместимость версий виджетов на проде); - организационные (например, команды не успеют протестировать изменения в срок); - продуктовые (например, возможный downtime для пользователей). - Укажи вероятность (низкая/средняя/высокая) и возможный эффект. Это поможет оценить, насколько риски можно смягчить. ## 5. План отката - Опиши условия, при которых будет выполнен откат (роллбек) и/или реверт. - Если возможно, укажи план по хотфиксам для быстрого исправления проблем. ## 6. Рассмотренные альтернативы (при необходимости) - Перечисли варианты решений, которые были рассмотрены. - Для каждого варианта укажи плюсы и минусы. - Объясни, почему выбран текущий подход. ## 7. Примерный таймлайн (опционально) - Дата начала работ. - Ключевые этапы и дедлайны. - Примерная дата завершения. ## 8. Согласовано - Укажи всех участников согласования. - При аппрувке можно оставить комментарий. Так же здесь указывается список разработчиков, которые аппрувнули RFC.
Итог
Мы взяли хаос и превратили его в предсказуемый процесс.
Глобальные изменения теперь проходят одинаково, прозрачно и безопасно.
И самое важное — разработчикам стало проще инициировать изменения, потому что больше не нужно пробивать стену из неопределённости.
Если вы тоже живёте в монорепе — надеюсь, наш опыт окажется полезным.