Перевод статьи подготовлен для студентов курса «DevOps практики и инструменты» в образовательном проекте OTUS.

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

Почему мы говорим об этом?

Мэтт Кляйн (Matt Klein) написал статью «Monorepos: Please don’t!» (прим. переводчика: перевод на хабре «Монорепозитории: пожалуйста не надо»). Мне нравится Мэтт, я думаю, что он очень умён, и вы должны прочитать его точку зрения. Первоначально он опубликовал опрос в твиттере:

Перевод:
В этот новогодний день я поспорю о том, насколько нелепы монорепозитории. 2019 год начался незаметно. В духе этого я предлагаю вам опрос. Кто большие фанатики? Сторонники:
— Монорепозитория
— Rust
— Неправильный опрос / и те и те

Мой ответ был: «Я буквально оба этих человека». Вместо того чтобы говорить о том, какой Rust наркотик, давайте разберёмся, почему я думаю, что он ошибается насчёт монорепозиториев. Немного о себе. Я технический директор Chef Software. У нас около 100 инженеров, кодовая база, насчитывающая около 11–12 лет, и 4 основных продукта. Часть этого кода находится в полирепозитории (моя стартовая позиция), часть в монорепозитории (моя текущая позиция).

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

Я согласен с первой частью точки зрения Мэтта:

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

Вам предстоит решить одинаковые проблемы вне зависимости от того выберете вы монорепозиторий или полирепозиторий. Как вы выпускаете релизы? Какой у вас подход к обновлениям? Обратная совместимость? Перекрёстные зависимости проектов? Какие архитектурные стили приемлемы? Как вы управляете своей инфраструктурой сборки и тестирования? Список бесконечен. И вы будете решать их все по мере того, как растёте. Бесплатного сыра не бывает.

Я думаю, что аргумент Мэтта похож на взгляды, разделяемые многими инженерами (и менеджерами), которых я уважаю. Это происходит с точки зрения инженера, работающего над компонентом, или команды, работающей над компонентом. Вы слышите такие вещи, как:

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

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

Он провоцирует общение и показывает проблемы

Когда мы разделяем репозитории, мы де-факто создаём проблему координации и прозрачности. Это соответствует тому, как мы думаем о командах (особенно тому, как думают о них отдельные участники): мы несём ответственность за определённый компонент. Мы работаем в относительной изоляции. Границы фиксируются на моей команде и компоненте (-ах), над которым мы работаем.

При усложнении архитектуры одна команда уже не может больше управлять ею в одиночку. Очень немногие инженеры держат всю систему в голове. Допустим, вы управляете общим компонентом A, который используется командами B, C и D. Команда A проводит рефакторинг, улучшает API, а также изменяет внутреннюю реализацию. В результате изменения являются обратно не совместимыми. Какой совет вы дадите?

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

Обратите внимание, что эти вопросы не зависят от типа репозитория. Вам нужно будет найти команды B, C и D. Вам нужно будет поговорить с ними, выяснить время, понять их приоритеты. По крайней мере мы надеемся, что вы это сделаете.

На самом деле никто не хочет заниматься этим. Это гораздо менее увлекательно, чем просто исправление чёртового API. Всё это человеческое и запутанное. В полирепозитории вы можете просто внести изменения, дать на ревью тем, кто работает над этим компонентом (вероятно, не B, C или D), и двигаться дальше. Команды B, C и D могут пока просто оставаться на своей текущей версии. Они обновятся, когда осознают вашу гениальность!

В монорепозитории ответственность сдвигается по умолчанию. Команда A меняет свой компонент и, если не проявит осторожности, немедленно ломает B, C и D. Это приводит к тому, что B, C и D появляются у двери A, удивляясь, почему команда A сломала сборку. Это учит A тому, что они не могут пропустить мой список выше. Они должны говорить о том, что они собираются делать. Могут ли B, C и D двигаться? Что, если B и C могут, но D был тесно связан с побочным эффектом поведения старого алгоритма?

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

Поддержка нескольких внутренних API, при этом старый алгоритм будет помечен устаревшим, пока D не сможет прекратить его использовать.
Поддержка нескольких версий релизов, одна со старым интерфейсом, одна с новым.
Задержка релиза изменений A до тех пор, пока одновременно B, C и D не смогут принять его.

Допустим, мы выбрали 1, несколько API. В этом случае у нас есть два куска кода. Старый и новый. Довольно удобно в некоторых ситуациях. Мы возвращаем старый код обратно, помечаем устаревшим (deprecated) и согласовываем график его удаления с командой D. По существу идентично для поли и для монорепозитория.

Для релиза нескольких версий нам нужна ветка. Теперь у нас есть два компонента — А1 и А2. Команды B и C используют A2, а D использует A1. Нам нужно, чтобы каждый компонент был готов к релизу, потому что, прежде чем D сможет двигаться дальше, могут потребоваться обновления безопасности и исправления других ошибок. В полирепозитории мы можем спрятать это в долгоживущей ветке, которая чувствует себя хорошо. В монорепозитории мы принудительно создаём код в новом модуле. Команде D всё ещё придётся вносить изменения в «старый» компонент. Каждый может увидеть стоимость, которую мы здесь платим — у нас теперь вдвое больше кода, и любые исправления ошибок, которые применяются к A1 и A2, должны применяться для них обоих. С подходом использования веток в полирепозитории это скрыто за cherry-pick. Мы считаем стоимость как меньшую, потому что там нет дублирования. С практической точки зрения, стоимость одинакова: вы будете создавать, выпускать и поддерживать две, в основном идентичные, базы кода до тех пор, пока не сможете удалить одну из них. Разница в том, что у монорепозитория эта боль прямая и она на виду. Это ещё хуже, и это хорошо.

Наконец, мы добрались до третьего пункта. Задержка релиза. Возможно, что изменения, внесённые А, улучшат жизнь команды А. Важно, но не срочно. Можем ли мы просто задержать? В полирепозитории мы подталкиваем это к закреплению артефакта. Конечно, мы говорим об этом команде D. Просто оставайтесь на старой версии, пока не догоните! Это настраивает на игру в труса. Команда A продолжает работать над своим компонентом, игнорируя тот факт, что команда D использует всё более устаревшую версию (это проблема команды D, они глупые). Тем временем команда D говорит плохо о неосторожном отношении команды A к стабильности кода, если они вообще говорят об этом. Проходят месяцы. Наконец, команда D решает взглянуть на возможность обновления, но изменений в A стало только больше. Команда А едва помнит, когда и как они сломали D. Обновление более болезненно и займёт больше времени. Что отправляет его дальше вниз по стеку приоритетов. До того дня, пока у нас не возникнет проблема безопасности в А, что заставляет нас делать ветку. Команда A должна вернуться назад во времени, найти момент, когда D был стабильным, исправить там проблему и сделать его готовым к релизу. Это де-факто выбор, который делают люди, и он, безусловно, худший. Кажется, что это хорошо как для команды A, так и для D, пока мы можем игнорировать друг друга.

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

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

Да, вы можете создать инструменты, которые попытаются решить проблему полирепозиториев. Но мой опыт обучения непрерывной поставке (continuous delivery) и автоматизации на крупных предприятиях говорит мне следующее: поведение по умолчанию без использования дополнительных инструментов — это то поведение, которое вы ожидаете видеть. Поведение полирепозитория по умолчанию — изоляция, вот и весь смысл. Поведение монорепозитория по умолчанию — это общая ответственность и прозрачность, вот и весь смысл. В обоих случаях я собираюсь создать инструмент, который позволит сгладить острые углы. Как руководитель, я буду выбирать монорепозиторий каждый раз, потому что инструменты должны укреплять культуру, которую я хочу, а культура исходит из крошечных решений и ежедневной работы команды.

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