Монорепа — это удобно.
Пока тебе не нужно внести глобальные изменения.

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

В итоге все боялись глобальных изменений и каждое обновление Angular превращалось в приключение.

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

Эта статья — про то, зачем он нужен, как он построен и какие проблемы решает.

Когда стало понятно, что без процесса — никак

Монорепа живёт по своим правилам. В отличие от отдельных репозиториев, здесь глобальное изменение может:

• сломать десятки проектов одновременно;

• потребовать межкомандного тестирования;

• привести к несовместимости версий виджетов на проде;

• вызвать прямые финансовые убытки.

Когда процесса нет, происходит следующее:

• RFC пишут кто как умеет и когда вспомнит;

• ревью застревает, потому что непонятно, кто обязан смотреть;

• тестирование теряется между задачами команд;

• релизы выкатываются в разные дни, ломая совместимость;

• нет ясности, кому эскалировать, если всё стопорится.

Мы пришли к очевидному выводу: глобальные изменения должны идти по формальному, прозрачному и единому маршруту.

Что считается «глобальным» изменением

Процесс обязателен для изменений, которые:

• затрагивают всю монорепу;

• могут сломать работу проектов;

• требуют межкомандного тестирования;

• несут риск убытков или деградаций.

Примеры:

• обновление Angular или других ключевых пакетов;

• переход на новый сборщик или архитектурный подход;

• крупные миграции, затрагивающие MFE, shared-библиотеки, CI.

Не требуют процесса:

• минорные патчи зависимостей;

• небольшие конфигурационные правки;

• добавление безопасных и популярных библиотек.

Для них достаточно MR с тегом дежурных по монорепе.

Почему мы ввели обязательный RFC и строгий шаблон

Раньше это выглядело так:

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

Мы решили полностью прекратить такой хаос.

RFC — это не бюрократия, а инструмент, который обеспечивает:

• единый формат для целей, рисков, плана и отката;

• прозрачность для всех команд;

• предсказуемость сроков;

• документ, который можно поднять через полгода и понять контекст.

Мы сделали строгий шаблон RFC, где есть:

1. цель и проблема;

2. план действий;

3. затрагиваемые команды;

4. риски;

5. план отката;

6. альтернативы;

7. таймлайн;

8. список согласовавших.

И самое важное есть 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.

Итог

Мы взяли хаос и превратили его в предсказуемый процесс.
Глобальные изменения теперь проходят одинаково, прозрачно и безопасно.

И самое важное — разработчикам стало проще инициировать изменения, потому что больше не нужно пробивать стену из неопределённости.

Если вы тоже живёте в монорепе — надеюсь, наш опыт окажется полезным.