AI Пример процесса внесения глобальных изменений в большой монорепозиторий

[AI]

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

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

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

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

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

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


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

• 
  сломать десятки проектов одновременно;
  
  
• 
  потребовать межкомандного тестирования;
  
  
• 
  привести к несовместимости версий виджетов на проде;
  
  
• 
  вызвать прямые финансовые убытки.
  

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

• 
  RFC пишут кто как умеет и когда вспомнит;
  
  
• 
  ревью застревает, потому что непонятно, кто обязан смотреть;
  
  
• 
  тестирование теряется между задачами команд;
  
  
• 
  релизы выкатываются в разные дни, ломая совместимость;
  
  
• 
  нет ясности, кому эскалировать, если всё стопорится.
  

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

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


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

• 
  затрагивают всю монорепу;
  
  
• 
  могут сломать работу проектов;
  
  
• 
  требуют межкомандного тестирования;
  
  
• 
  несут риск убытков или деградаций.
  

Примеры:

• 
  обновление Angular или других ключевых пакетов;
  
  
• 
  переход на новый сборщик или архитектурный подход;
  
  
• 
  крупные миграции, затрагивающие MFE, shared-библиотеки, CI.
  

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

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

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

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


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

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

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

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

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

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

1. 
   цель и проблема;
   
   
2. 
   план действий;
   
   
3. 
   затрагиваемые команды;
   
   
4. 
   риски;
   
   
5. 
   план отката;
   
   
6. 
   альтернативы;
   
   
7. 
   таймлайн;
   
   
8. 
   список согласовавших.
   

И самое важное есть SLA:

• 
  ревью RFC — до 3 рабочих дней;
  
  
• 
  при отсутствии реакции — официальный пинг каждые 24 часа;
  
  
• 
  если игнор продолжается — эскалация на CTO;
  
  
• 
  и другие шаги, чтобы инициативы доводились до конца в разумные сроки.
  

Полный процесс глобальных изменений

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 создают задачи у себя;
  
  
• 
  ответственный следит, чтобы тестирование реально началось.
  

Если что-то ломается:

• 
  либо фиксит инициатор;
  
  
• 
  либо, по договорённости, команда, чья зона ответственности пострадала.
  

После подтверждений всех команд задача переходит в «готово для релиза».

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.

Итог


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

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

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