Монорепозитории: пожалуйста не надо

Автор оригинала: Matt Klein
  • Перевод
От переводчика: Привет, Хабр! Да, это очередная статья о преимуществах и недостатках монорепозиториев. Собирался написать свою статью о том, как мы используем монорепозиторий, как мы переходили с maven на bazel и что из этого получилось. Но пока собирался с мыслями, вышла отличная статья от разработчика из Lyft, которую я и решил для вас перевести. Обещаю опубликовать свои дополнения к статье, а также опыт с bazel в виде продолжения.
Мы в Новом 2019 году, и я настроен на еще одну дискуссию о преимуществах (или отсутствии таковых) в хранении всего исходного кода организации в «Монорепозитории». Для тех из вас, кто не знаком с этим подходом, идея состоит в том, чтобы хранить весь исходный код в едином репозитории системы контроля версий. Альтернатива, конечно, заключается в том, чтобы хранить исходный код в нескольких независимых репозиториях, разделяя их обычно по границе сервисов/приложений/библиотек.

В данном посте я буду называть такой подход «полирепозиторий».

Некоторые из ИТ-гигантов используют монорепозитории, включая Google, Facebook, Twitter и других. Конечно, если такие уважаемые компании используют монорепозитории, то преимущества такого подхода должны быть огромны, и мы все должны делать так же, верно? Нет! Как сказано в заголовке статьи: «Пожалуйста, не используйте монорепозиторий!» Почему? Потому что на большом масштабе монорепозиторий будет решать все те же самые проблемы, которые решает и полирепозиторий, но при этом провоцируя вас к сильной связанности вашего кода и требуя невероятных усилий по увеличению масштабируемости вашей системы контроля версий .

Таким образом, в среднесрочной и долгосрочной перспективе монорепозиторий не дает никаких организационных преимуществ, в то время как оставляет лучших инженеров компании с пост-травматическим синдромом (проявляется в виде пускания слюней и бессвязного бормотания о производительности git).


Короткое отступление: что я подразумеваю под «на большом масштабе»? Нет однозначного ответа на этот вопрос, но т.к. я уверен, что вы спросите меня об этом, давайте скажем, что это около 100 разработчиков, пишущих код фул-тайм.

Теоретические преимущества монорепозитория и почему они не могут быть достигнуты без инструментов, которые используются для полирерозиториев (или ложны)


Теоретическое преимущество 1: более легкая коллаборация и совместное владение кодом


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

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

1) нечто вроде виртуальной файловой системы, которая позволяет хранить локально только часть кода. Это может быть достигнуто с помощью проприетарной файловой системы как Perforce, которая поддерживает такой режим нативно, с помощью внутреннего инструмента G3 от Google или GVFS от Microsoft.

2) сложные инструменты как сервис (as a service) для индексирования/поиска/просмотра исходного кода. Т.к. никто из разработчиков не собирается хранить весь исходный код на своей рабочей станции в состоянии, пригодном для поиска, становится критичным иметь возможность проводить такой поиск по всей кодовой базе.

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

В контексте индексирования/поиска/просмотра и сходного кода такой гипотетический инструмент с легкостью может осуществлять поиск и по нескольким репозиториям и объединять результат. Фактически именно так работает поиск на GitHub, так же как и более сложные инструменты для поиска и индексирования, такие как Sourcegraph.

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

Теоретическое преимущество 2: одна сборка / нет управления зависимостями


Следующий аргумент, приводимый обычно сторонниками монорепозиториев, заключается в том, что хранение всего кода в одном монорепозитории лишает вас необходимости управлять зависимостями, т.к. весь код собирается в одно и то же время. Это ложь! На большом масштабе просто нет возможности пересобирать весь исходный код и прогонять все автоматизированные тесты каждый раз, когда кто-то коммитит изменения в систему контроля версий (или что более важно и чаще встречается, на сервере CI когда создается новая ветка или пулл-реквест). Чтобы решить эту проблему все большие монорепозитории используют свою сложную систему сборки (например Bazel/Blaze от Google или Buck от Facebook), которая спроектирована так, что следит за изменениями и их зависимыми блоками и строит граф зависимостей исходного кода. Этот граф позволяет организовать эффективное кэширование результатов сборки и тестов, так что только изменения и их зависимости нуждаются в пересборке и тестировании.

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

Сторонники монорепозиториев также будут утверждать, что даже с учетом необходимости отслеживания сборок/зависимостей это все равно дает неоспоримое преимущество, т.к. одиночный коммит описывает полное состояние всего мира. Я бы сказал, что это преимущество довольно спорное, учитывая, что граф зависимостей уже существует, и это выглядит довольно тривиальной задачей включить идентификатор коммита для каждого независимого репозитория как часть этого графа, и фактически Bazel может легко работать с несколькими независимыми репозиториями как и с одним монорепозиторием, абстрагируя нижележащий уровень от разработчика. Более того, легко можно реализовать такие средства автоматизированного рефакторинга, которые автоматически обновляют версии зависимых библиотек в нескольких независимых репозиториях сразу, нивелируя разницу между монорепозиторием и полирепозиторием в этой части (более подробно об этом дальше).

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

Теоретическое преимущество 3: рефакторинг кода — это простой атомарный коммит


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

1) как было описано выше, на большом масштабе разработчик не будет способен редактировать или осуществлять поиск по всей кодовой базе на своей локальной машине. Таким образом, идея о том, что каждый может легко склонировать себе весь репозиторий и просто выполнить grep/replace, не так легко осуществима на практике.

2) даже если мы предположим, что с помощью сложной виртуальной файловой системы разработчик может клонировать и редактировать всю кодовую базу, то как часто это будет происходить? Я не говорю про исправление бага в имплементации общей библиотеки, т. к. такая ситуация одинаково обрабатывается и в случае монорепозитория, и в случае полирепозитория (предполагая похожую систему сборки/деплоя, как описано выше). Я говорю об изменении API библиотеки, за которым последуют множество ошибок компиляции в тех местах, где эта библиотека вызывается. В очень большой кодовой базе почти невозможно сделать изменение базового API, которое будет проревьюено всеми задействованными командами до того, как мердж конфликты заставят вас начать процесс сначала. У разработчика есть 2 реальные возможности: он может сдаться и придумать обходной путь для проблемы с API (на практике это случается чаще, чем нам всем этого бы хотелось), или он может задепрекейтить существующий API, написать новый API и затем вступить на тропу долгого и мучительного обновления всех вызовов старого API по всей кодовой базе. В любом случае это абсолютно такой же процесс, как и при полирепозитории.

3) в сервис-ориентированном мире приложения состоят из множества слабо связанных компонентов, которые взаимодействуют между собой, используя некоторый тип хорошо описанного API. Большие организации рано или поздно переходят на использование IDL (язык описания интерфейсов), таких как Thrift или Protobuf, которые позволяют делать типо-безопасные API и производить обратно-совместимые изменения. Как было описано в предыдущем разделе о сборке/деплое, код не может быть задеплоен одномоментно. Он может деплоиться на протяжении некоторого периода времени: часов, дней или даже месяцев. Поэтому разработчики обязаны думать об обратной совместимости своих изменений. Такова реальность современной разработки ПО, которую многие хотели бы игнорировать, но не могут. Поэтому, когда это касается сервисов (в противовес API библиотек) разработчики должны использовать один из двух подходов, описанных выше (не менять API или пройти через цикл депрекации) и это абсолютно одинаково и для монорепозитория, и для полирепозитория.

К слову о рефакторинге на большой кодовой базе, многие большие организации приходят к тому, чтобы разработать свои автоматизированные инструменты для автоматического рефакторинга, как например fastmod, недавно выпущенный Facebook. Как и всегда, этот инструмент мог бы с легкостью работать с одним репозиторием или же несколькими независимыми. У Lyft есть инструмент, который называется «refactorator», который делает именно это. Он работает как fastmod, но автоматизирует изменения по нескольким нашим репозиториям, включая создание пулл-реквестов, отслеживание статусов ревью и т.д.

Уникальные недостатки монорепозиториев


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

Недостаток 1: сильная связанность и ПО с открытым исходным кодом


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

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

Сильное связывание также имеет серьезные последствия относительно открытия своих исходных кодов. Если компания хочет создавать или потреблять ПО с открытым кодом, использование полирепозиториев просто необходимо. Искажения, которые происходят, когда компания пытается выложить свой проект в open source из своего монорепозитория (импорт/экспорт исходных кодов, публичный/приватый баг трекер, дополнительные слои для абстрагирования разницы в стандартных библиотеках и т.д.) не приводят к продуктивной коллаборации и построению сообщества, а также создают существенные накладные расходы.

Недостаток 2: масштабируемость системы контроля версий



Масштабирование системы контроля версий для сотен разработчиков, сотен миллионов строк кода, и огромного потока коммитов — монументальная задача. Монорепозиторий Twitter, созданный 5 лет назад (на основе git), был одним из самых бесполезных проектов, которые я наблюдал за свою карьеру. Выполнение простейшей команды как git status занимало минуты. Если локальная копия репозитория слишком устаревала, обновление могло занять часы (в то время даже была практика отправлять жесткие диски с копией репозитория удаленным сотрудникам со свежей версией кода). Я вспоминаю об этом не для того, чтобы поиздеваться над разработчиками Twitter, а чтобы проиллюстрировать, как сложна эта проблема. Я могу сказать, что 5 лет спустя, производительность монорепозитория Twitter все еще далека от той, которую хотели бы видеть разработчики Туллинг команды, и это не потому, что они плохо старались.

Конечно, за эти 5 лет в этой области происходило некоторое развитие. Git VFS от Microsoft, которая используется для разработки Windows, привела к тому, что появилась настоящая виртуальная файловая система для git, которую я описывал выше как необходимое условие для масштабирования системы контроля версий (и с покупкой Microsoft Github похоже, что этот уровень масштабирования найдет свое применение в фичах, которые GiHub предлагает своим корпоративным клиентам). И конечно, Google и Facebook продолжают вкладывать огромные ресурсы в свои внутренние системы, чтобы они продолжали функционировать, хотя почти ничего из этого не доступно публично.

Так почему нужно вообще решать эти проблемы с масштабированием системы контроля версий, если как описано в предыдущем разделе, инструментарий требуется ровно тот же самый, что и для полирепозитория? Для этого нет разумной причины.

Заключение


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

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

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 85

    +4
    очень интересно наблюдать как хайпили по микросервисам против монолита, а сейчас за монорепо против сервис-реп
      +1
      О да. Мы недавно публиковали достаточно детальное выступление по «анти-хайпу» микросервисов :-)
      +7
      Мне нравится делать
      docker-compose up
      в корне монорепы и получать целиком рабочий проект. И эту команду выполняет каждый разработчик каждый день и она редко ломается, показывает как проект работает целиком. Монорепа уменьшает страхи сделать ещё один подпроект в виде микросервиса (в большой компании вам нужно пройти все круги ада на одобрение такого и рассказать всей команде, что нужно запускать +1 проект в деве). Единый процесс CI/CD, который крайне просто менять, потому что он один, а не 10+ в разных проектах (infrastructure as code, сейчас код деплоя лежит рядом с кодом приложения).

      На другой стороне примеры проектов с десятком репозиториев, которые поддерживаются уже второй-третий год. Чтобы запустить каждый нужно немного магии, немного магии * 10 — это крайне МНОГО магии. Часто граф зависимостей не описан.

      В идеальной компании полирепозиторий — хорошо, но такий крайне мало. В стартапе на 3-5 человек 10 репозиториев не нужны.

      PS. Мы держим каждый frontend на react отдельно, потому что чисто фронтендщики не хотят заморачиваться или это не позволяет делать windows без боли. А весь бек лежит в монорепе.
        +3
        Смотрите, как это сделано у нас: есть репозиторий с инфраструктурой, к нему через git-submodules подключены уже конкретные проекты. По умолчанию субмодули не выкачиваются. А сборщик умеет выкачивать субмодули по требованию. При этом разработчик может в любой момент переключить любой субмодуль на любую ветку. А когда надо сделать релиз — в инфраструктурной репе комитятся новые ревизии субмодулей.
          +9
          Я боюсь submodules. Только печальные практики с ним. Скорее всего я не умею готовить. Может подскажите полезные статьи?
              +2
              Крайне сложно работать в ветках и не сломать себе мозг при обновлении нескольких submodules. Я сломал.
                0
                Переходили с subtree на submodule пару лет назад. Сперва было больно, а потом ничего, понравилось. Из плюсов — быстрая синхронизация кода (и предсказуемая)
                из минусов — надо всегда держать в голове, какие коммиты ты должен сохранить и не ребейзить (обычно это все release/* ветки, но бывают исключения).
                Мне они нравятся из-за какой-то своей ODR-ности, что ли.
                В один репозиторий 10-15 сабмодулей подключается если что.
                  0
                  Эта проблема решается крайне просто: не ребейзить вообще.
                  0
                  Если вы активно работаете с самими подмодулями, тогда возможно. Из моей практики единственное место которое влекло за собой «поломку» проекта, это вынос части проекта в отдельный подмодуль. В таком случае проблемы были только с выкачиванием\мерджем более старых веток у других людей, и то это разовая проблема.
              +1

              Сабмодули можно использовать как раз для создания надрепозитрия (или мета-репозитория) вокруг нескольких независимых полиреп. В него можно положить compose для запуска всего проекта целиком как alexesDev любит

                0

                Проблема с сабмодули, что они ссылаются на конкретный коммит. Таким образом, держать такой репозиторий в актуальном состоянии довольно трудно. Можно, конечно, автоматизировать, чтобы всегда вытягивать, например, свежие релизные версии… Но не очень понятно, какую проблему это решает. Если хочется запускать полностью всю систему локально, то проще залить артифакты в registry/bintray/куда-то ещё и точно также запустить docker-compose

                  0

                  git-subtree (https://habr.com/post/429014/) по идее должен решать эту проблему, но я его пока не использовал, так что ничего сказать не могу.


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

                    0
                    subtree сильно хуже, когда есть несколько слабо зависимых команд и надо периодически между ними синхронизировать код.
                    сабмодули позволяют грубо говоря всегда иметь точно ту же самую версию кода.
                    subtree в принципе может быть вариантом, если конкретный репозиторий всегда меняет ровно одна команда и никакая другая (так что конфликты исключены). Иначе — не в ту сторону решенный конфликт является багом замедленного действия (который ты не выявишь diff-ом, ибо дифф-то и должен быть в ситуации правок с нескольких источников).

                    0
                    Есть еще проблема с бранчами, когда в рамках одной фичи нужно отбранчить код в нескольких, связанных сабмодулями репозиториях. Дело в том, что ссылки на сабмодули в фича-бранче родительского репозитория будут указывать на коммиты в мастере. Тогда даже автоматизация через git submodule update не помогает. Есть волшебная пилюля для такого сценария?
                      0
                      А как вы собираетесь деплоить эти связанные изменения?
                      Я бы сказал, что если у вас есть сильная связь между репозитоиями, вы неправильно определили границы.
                      Если все же границы определены верно, то не нужно писать этот код вместе — добавьте изменения в первый репозиторий, задеплойте его, потом добавьте во второй — задеплойте его.
                        0

                        В гите нет веток. Есть только ревизии и указатели на ревизии. Субмодуль может указывать на любую ревизию. Даже если после неё нет ревизии, на которую указывает мастер. А git submodule update не смотря на название просто выкачивает эту самую ревизию в рабочую копию. У гита всё плохо с командами, да.

                      +1

                      А чем это отличается от обычного монорепа? Например, тот же svn уже стопицот лет умеет partial checkout, и каждый подкаталог, и даже файл можно выкачать нужной ревизии. Только, в отличие от git'а, выкачивается не вся история, а только нужная ревизия.

                      +3

                      Это правда, что в проекте из 2-3 человек не нужно несколько репозиториев. Это просто добавить слишком много накладных расходов. Так что это вполне естественно начинать проект с монорепозитория. Проблемы начинаются тогда, когда у вас 200+ разработчиков, 500+ комитетов в день и билд занимает 40 минут.
                      Главное не пропустить тот момент, когда код будет настолько связан, что разделить его уже не получится

                        +1
                        Это правда, что в проекте из 2-3 человек не нужно несколько репозиториев. Это просто добавить слишком много накладных расходов.

                        Это зависит не от количества людей, а от сложности проекта.

                        Одно из преимуществ, которое мне нравится — подмодули заставляют тебя так декомпозировать код, что ты не можешь сделать проекты A и B взаимозависимыми (если всё правильно организовано). А если случайно так получилось, — это требуется исправить, а результат гарантированно можно проверить, просто собрав эти два подмодуля по-отдельности.

                        Ещё одно преимещуство — это пакетирование. CI/CD автоматически собирает каждый проект, отдельно его тестирует и пакетирует, например, в свой deb- или rpm-пакет под заданные платформы. Но тут сложнее, т. к. требуется автоматизировать зависимую сборку проектов. Зато не требуются такие надстройки как над монорепозиторием.

                        Ещё одно преимущество — можно делать глобальный рефакторинг не по всему проекту сразу, а частями через подмодули, таким образом распределив задачу по разным людям. При этом нигде ничего не ломается.
                          0
                          > Это зависит не от количества людей, а от сложности проекта.

                          И от количества людей тоже (мало людей не смогут нагенерировать поток коммитов и создать проблемный размер для репозитория), так что если 2-3 человека, то основные проблемы монорепозитория не очень проявляют себя.

                          > Одно из преимуществ, которое мне нравится — подмодули заставляют тебя так декомпозировать код,

                          Это указано в статье, тоже считаю это преимуществом

                          > Ещё одно преимещуство — это пакетирование.

                          вот тут не вижу взаимосвязи с моно- или полирепозиторием, мы в своем монорепозитории собираем отдельные пакеты для каждого микросервиса под разные платформы, работало и на maven, работает и на bazel

                          > Ещё одно преимущество — можно делать глобальный рефакторинг не по всему проекту сразу, а частями через подмодули

                          ну прямо скажем, в монорепозитории тоже так можно. Даже более того, (об этом сказано в статье) другого варианта у вас нет даже в монорепозитории из-за неатомарности деплоя.
                            0
                            вот тут не вижу взаимосвязи с моно- или полирепозиторием, мы в своем монорепозитории собираем отдельные пакеты для каждого микросервиса под разные платформы, работало и на maven, работает и на bazel

                            К сожалению Java хоть и знаю, но в продакшене пока ещё не использую (равно как и монорепозитории, которые с самого начала решил не делать), поэтому мне сложно в этом контексте что-либо оценивать.

                            Идея, которую я пытался донести в том, что каждый подпроект описывается отдельно и подключается там, где это требуется как подмодуль. При этом сам подпроект обрабатывается Gitlab (CI/CD) как самостоятельный проект, который не знает о существовании чего-либо ещё. При этом для каждого проекта создаётся шаблонный yaml-файл для CI/CD в котором по сути меняется лишь название проекта. А сама сборка осуществляется с помощью ещё одного универсального подмодуля, который подключается к каждому проекту. А уже этот подмодуль берёт из проекта файл конфигурации под каждую платформу для текущего проекта.

                            В результате любой разработчик может быстро склонировать всего лишь один репозиторий (с рекурсивными зависимостями), перейти на любой коммит и собрать пакет, например, для тестов. Или тесты прогнать, дописав новый. Система сборки в этом случае будет самодостаточной.
                        +9

                        Если у вас проект целиком запускается на одной машине, это маленький проект ;)
                        В моей практике была система, минимальная конфигурация которой содержала 20 виртуалок. Никто даже не пытался запускать ее на локальной машине, т.к. там было несколько инстансов Оракла с кросс-локейшн репликацией

                          +3

                          А с меньшим количеством инстансов оракла эта система не способна работать?

                            +2
                            Не поверите, но нет :)
                            Это не ноды одного кластера, а независимые подсистемы
                            В подробности вдаваться не буду, просто поверьте на слово ;)
                          +6
                          А разве суть микросервисов не в том, чтобы их можно было запускать и разрабатывать отдельно?
                            0

                            Частично да, но иногда, к сожалению, нужно протестировать интеграционные сценарии. А что того хуже, иногда их нужно ещё и продебажить. Так что хорошо иметь возможность запустить хотя бы часть системы (несколько сервисов, в зависимости от воспроизводимого сценария) локально из IDE в дебаг режиме

                              +4
                              Я в основном отвечал на «docker-compose up и все запущено». Как-то это не микросервисно. Поднимать несколько сервисов можно и иногда нужно, но это не должно быть обязательным требованием.
                          –2
                          Автор неправ. Аргументы за — какие-то высосанные из пальца. Из серии «сам придумал — сам с собой поспорил».
                          Потому что, на большом масштабе монорепозиторий будет решать все те же самые проблемы, которые решает и полирепозиторий, но при этом провоцируя вас к сильной связанности вашего кода и требуя невероятных усилий по увеличению масштабируемости вашей системы контроля версий. Таким образом, в среднесрочной и долгосрочной перспективе монорепозиторий не дает никаких организационных преимуществ, в то время как оставляет лучших инженеров компании с пост-травматическим синдромом (проявляется в виде пускания слюней и бессвязного бормотания о производительности git).

                          что я подразумеваю под «на большом масштабе»? Нет однозначного ответа на этот вопрос, но т.к. я уверен, что вы спросите меня об этом, давайте скажем, что это около 100 разработчиков, пишущих код фул-тайм.

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

                          Следующий аргумент, приводимый обычно сторонниками монорепозиториев, заключается в том, что хранение всего кода в одном монорепозитории лишает вас необходимости управлять зависимостями, т.к. весь код собирается в одно и то же время. Это ложь! На большом масштабе просто нет возможности пересобирать весь исходный код и прогонять все автоматизированные тесты каждый раз, когда кто-то коммитит изменения в систему контроля версий


                          На больших проектах монорепозиторий действительно не нужен. Но на малых проектах, или в малых командах (и особенно если всего 1 разработчик), или вообще в начале проекта — монорепозиторий очень удобен. Если проект-прототип получит развитие, то уже далее, в какой-то момент монорепозиторий надо будет разделить.

                          Проведу некую аналогию — было множество споров, что лучше — монолит или микросервисы. У каждой из архитектур свои + и -. Я считаю что существует промежуточный вариант — микросервисный монолит, который будет жить в монорепозитории. Он хорош на старте проекта, и если проект «взлетит» и получит развитие, то будет рефакторинг в честные микросервисы и разные репозитории.
                            +8

                            Ну в статье и говорится не об одном разработчике, а о проекте с 100+ разработчиками.
                            Могу сказать по своему опыту, про темы совсем невыдуманные. Особенно в части того, что некоторые компании бездумно копируют практики.
                            В данный момент у нас 200+ инженеров работают над монорепозиторием. Более 100 коммитов в день, билд на CI занимает около 40 минут. Клонирование репозитория с Гитхаба (учитывая поганый Австралийский интернет) занимает больше 10 минут.
                            Я уж не говорю про индекс в Идее

                              –4
                              Так основной посыл статьи — не используйте монорепо вообще никогда. Это тоже бездумная рекомендация. Мой комментарий про ограничения применимости.
                                +10
                                Cлушайте, если у вас один разработчик, то у вас не «монорепозиторий», а «репозиторчик». В том смысле, что там мало кода, и вообще пофиг на это. Посыл автора про большие команды. И, в основном, сторонники монорепы эти аргументы и приводят.
                            +1
                            У нас тоже монорепа и two-pizza team. Сначала было разделение на 2 репы — бек на джанго и фронт на реакте. Но это было банально неудобно. В итоге слили в один и довольны.

                            Про тесты — у нас в несколько потоков:
                            — бек интеграционные
                            — бек юнит
                            — фронт тесты
                            — фронт тест билда

                            Добавили маленькую проверку изменений в папке backend и frontend в CI чтобы зря не гонять тесты.

                            Все довольны :)
                              +17
                              Надо подчеркнуть, что в статье под «монорепозиторием» понимается не просто «несколько кусков проекта в одной репе» (скажем фронт и бек одного проекта), и даже не «несколько микросервисов в одной репе», а скорее подход trunk-based-development (аля гугл), где:
                              — одна репа на несколько *продуктов*, с разными командами, циклами релизов и т.п;
                              — в этой же репе лежат все «общие» компоненты, внутренние фреймворки, сервисы;
                              — но отсутсвие версий у библиотек/компонентов; по сути версия одна — номер коммита;
                              — нет (ну или почти нет) внешних зависимостей — вместо этого зависимости включаются в саму репу (подход аля Go).

                              Поэтому, имхо, немного неуместно говорить «а вот в нашем проекте на 3 человека и 5 микросервисом монорепа и все зашибись». Речь все же идет про разные «монорепы».
                                0

                                Вы абсолютно правы :)

                                  +3
                                  тогда это хорошо бы в дисклеймер к статье
                                  0
                                  Как по мне, отвечая на вопрос полирепозиторий или монорепозиторий — нужно ориентироваться на условия в которых будет выполняется разработка, а также личные предпочтения участников разработки. Остальное же, по моим мироощущениям, не так и важно. Если команде проекта удобно, то какая разница какой подход к организации репозитория они используют?!
                                  0
                                  Могу только отметить свой успешный опыт по внедрению монорепозитория. Раньше даже не думал, что так можно, всегда делал кучу репозиториев по дефолту, для меня монорепозиторий оказался просто идеалом.
                                    0
                                    Можете подробнее рассказать про свой опыт?
                                    0

                                    Оторвано от контеста.
                                    В случае с тем же JS'ом — есть lerna, хочешь монорепку — делай моно, хочешь полирепку — делай поли через git submodules. Погоды особо не делает.


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

                                      –2
                                      >> В разных языках — разные пакетные менеджеры, и очень мало жизнеспособного инструментария для монорепок.

                                      Не вижу проблемы положить несколько независимых продуктов в один реп в разные каталоги.
                                        0
                                        А зачем???
                                      0
                                      В php-проектах использую composer. Очень удобно обозначить зависимости и сохранить lock-файл, на проде просто установка из lock-файла. На случай если очень важно не потерять пакеты, можно сделать свой собственный «proxy» в виде satis. Не представляю что должно произойти чтобы пришлось отказаться от composer и хранить либы в репозитории.
                                      Еще есть вопрос по поводу универсальных либ которые удобно один раз написать и потом только использовать. Проблема в том что отладив либу для проекта, для другого почти наверняка придется сделать изменения которые могут сломать первый. Писать либу так чтобы было супер универсально далеко не всегда получается. Возможно в этом случае и полезны монорепозитории.
                                        +3

                                        Забавно, а мы сейчас в команде раздумываем над объединением наших пакетов в одно монорепо. Аргументы у нас такие:


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

                                        Размер команды – 10 человек. Если было бы на порядок больше, то там уже пришлось бы как-то разделять зоны отвественности и разъезжаться по отдельным репозиториям.

                                          –1
                                          Половину аргументов можно сходу отметать по той простой причине, что гит — это не про монорепы.
                                            0
                                            Что вы имеете в виду? Все исходники Windows хранятся в Гит, также как и ядро Linux.
                                              +1
                                              Ну так-то исходники винды лежат не совсем в гите, а линукс — это очень маленький проект по сравнению с кодовой базой фейсбука
                                                +1
                                                Тут возникает резонный вопрос: а нужно ли создавать себе проблемы с большими репозиториями, чтобы потом их героически решать? Не проще будет распилить большой проект на отдельные части?
                                                  0
                                                  Очевидно, до тех пор, пока вы не выросли до размеров гугла, фейсбука или даже яндекса — не нужно :)
                                                  0
                                                  Git Virtual File System en.wikipedia.org/wiki/Git_Virtual_File_System
                                                  Это к вопросу о том, где хранятся исходники Windows
                                                  +1

                                                  Когда в команде несколько десятков разработчиков, начинается гонка за коммит в head. В линуксе это работает благодаря организационной структуре: там изменения льются в апстрим по дереву доверия, и в каждом узле небольшое код-во разработчиков.

                                                    0
                                                    Для решения такой проблемы монорепощиторщики придумали свой тулинг :) называется мерджбот
                                                    Например prow от Goggle bentheelder.io/posts/prow или сервис mergify.io
                                                +2

                                                Я работал с большими кодовыми базами с использованием обоих подходов.


                                                Монорепы — это на порядок более удобный и продуктивный подход (полирепы вспоминаю как страшный сон), если у компании есть ресурсы для настройки (а возможно, и написания с нуля) инструментов для работы с ними. Facebook и Google выкладывают много полезного для этого кода в открытый доступ (Kythe, Bazel, Hg-experimental), но инвестировать в инфраструктуру придётся много.


                                                Не выйдет просто взять и начать сваливать весь код в одну кучу.

                                                  +1
                                                  Проблема со всеми этими проектами описана в статье.
                                                  Все они обладают очень сильной привязкой к специфике кодовой базы разработчика. Их просто невероятно сложно начать использовать. Говорю это, как человек, переведший монорепозиторий с мавена на bazel
                                                    +2

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

                                                      +1
                                                      Именно это и говорится в статье — есть ровно 20+- компаний в мире, которые умеют в монорепо. Это гугл, фейсбук, твиттер, яндекс, может быть, кто-то еще.
                                                      Остальным не надо даже пытаться, т.к. правильных инструментов у вас нет, как и ресурсов на их создание.
                                                        0
                                                        А в какой компании вы нынче монорепу используете?
                                                        И какие основные языки/технологии в вашей деятельности?
                                                          0
                                                          А вы в профиль загляните.
                                                            +1
                                                            С компанией лоханулся, признаю.
                                                            Списка языков и технологий там нет.
                                                            Есть определенная разница, использовать монорепу для бекэнда на плюсах, фронтенда на TypeScript или мобильных приложения для iOS и Android.
                                                            Если работает первый случай — это круто, но не интересно. Если второй и третий — это уже интересней.
                                                              0
                                                              Это же гугл. Там в общем и целом один монореп для всего и сразу. C++, Java, Python, Go (который родился в монорепе и поэтому там такой странный для внешнего пользователя менеджмент зависимостей), джаваскрипт, конечно. Под веб, айос, андроид, десктоп и все остальное что может прийти в голову.

                                                              Тайпскрипт тоже, да.
                                                                0
                                                                Ну и как вам для фронтэнда монорепа? Все ли чудесно и прекрасно?
                                                                  +1
                                                                  Нет, не все прекрасно. Но в целом работает.

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

                                                                  Интересное начинается когда добираешься до 3p кода (например популярные фреймверки, d3 и прочие antlr'ы).
                                                                    +1
                                                                    Интересное начинается когда добираешься до 3p кода

                                                                    Ну вообще говоря, c 3p не так уж всё и плохо. Как всегда с монорепами, это — проблема тулинга. Написаны инструменты для импорта сторонних зависимостей из разных источников и синхронизации с открытыми репозиториями. Очень многие популярные вещи уже в third_party.


                                                                    Зато получаем


                                                                    • codesearch по всем зависимостям
                                                                    • очередной leftpad вам ничего не сломает
                                                                    • вместо двух тысяч копий leftpad у вас будет ровно одна
                                                                    • версии всех зависимостей всегда консистентные (особенно актуально в каком-нибудь Haskell)
                                                                      0
                                                                      И плюс еще если надо слить/разъединить команды, то на структуре кода это не отражается.
                                                                        +1
                                                                        Так-то оно так, да не совсем. Вполне понятно для чего и почему сделано так и как оно сделано, но есть много нюансов.

                                                                        То же правило одной (на самом деле двух, для переходных периодов) версии — это палка о двух концах. С одной стороны — да, одна версия, которая всеми и используется. С другой стороны — выходит у пакета новая версия с breaking changes и все, у тебя 100+ проектов зависят от старой версии пакета, в репозитории жесткое правило одной версии, это пат. Надо обновить версию пакета и все зависимые проекты. А этим редко кто-то занимается. В результате в third_party свалка из неактуальных версий зачастую неактуальных пакетов, с которыми ничего толком не сделать. Для многих из них еще специально бекпортят фиксы безопасности, потому что нормально обновить не получается и как результат — что-то непонятное на выходе.

                                                                        Про то, что логика работы менеджмента зависимостей для фронтенда в принципе плохо ложится на рельсы монорепа (не только из-за вопросов версионирования) я расписывать не буду. По большому счету мне в codesearch не нужен код ВНЕШНИХ зависимостей, мне нужно только описание их API (exports.js + typings), которое там так и так присутсвует.

                                                                        Монореп может все-таки отдать управление ВНЕШНИМИ зависимостями на откуп стандартным инструментам, это ведь даже не сабмодули, просто код, который вам не принадлежит совсем. Гугл не может, по понятным и объективным причинам (security/privacy/legal), компания поменьше — может вполне.
                                                            +1
                                                            Однако адаптация хороших внешних инструментов под этот чудесный монолит — та еще задача, зачастую просто решаемая в лоб написанием своих собстенных «аналогичных» инструментов.

                                                            Я не так давно переводил один фронтенд-проект на 40+ тысяч строк с git/npm/gulp/webpack на эту чудесную монорепу, проклял все. Это еще повезло что он был наполовину на совсместимом наречии написан.
                                                              +2
                                                              40+ тысяч строк с git/npm/gulp/webpack на эту чудесную монорепу

                                                              На какую чудесную монорепу? В чём заключался перевод? Просто переписали билд на bazel/pants/buck?


                                                              Перевод проекта с системы сборки X на систему сборки Y, ∀ X, Y — это всегда много скучной, изматывающей, неблагодарной работы.


                                                              Я переводил ~500.000 строк кода и двумя десятками приложений на Java с кастомной ANT-сборки на Gradle, утомился. При чём тут монорепы?

                                                                +2
                                                                На ТУ САМУЮ чудесну монорепу про которую вы пишете выше.

                                                                Билд, это не самое интересное, это, как верно замечено, просто много скучной и изматывающей работы.

                                                                Самое интересное — это 3p зависимости, которые раньше подтягивались через стандартный для внешнего мира пакетный менеджер, а теперь должны быть частью собственно монорепы. В которой очевидное правило одной версии (очень далеко не всегда последней), определенные сложности с оформлением и добавлением пакетов из внешнего мира, очень плохая концептуальная совместимость с миром современного фронтенда в целом и еще разные сугубо внутренние нюансы.

                                                                Ну хотя это ведь тоже часть билда, если разбираться.
                                                              0
                                                              реализовывать кросс-модульные фичи — это просто сказка
                                                              Знаем-знаем. А потом без пол-литры не разберешь, а где же у этих систем границы. Где собственно зоны отвественности и все такое… Зла нет :)
                                                                +1
                                                                А потом без пол-литры не разберешь, а где же у этих систем границы. Где собственно зоны отвественности и все такое…

                                                                Это самый бредовый аргумент из всей статьи. У нас у каждой большой системы есть свой каталог с OWNERS файлами, в которых написано, кто владеет кодом. В нормальном воркфлоу без аппрува этой команды ничего изменить в их коде не получится. Всегда понятно, где границы, и кто за что отвечает. Сервисы взаимодействуют друг с другом через посылку сообщений поверх gRPC. Сложно представить себе более ясные границы.


                                                                Полирепы вас от плохого кода точно не спасут.

                                                                  0
                                                                  Ну OWNERS конечно хорошо, но от проблемы не спасает. Там может много кого, и аппрувят люди, которые далеко не всегда имеют досататочный контекст :)
                                                                  И взаимодействие через gRPC тоже не панацея. Оно может быть как в пределах одной системы (разбитой на куски), так и разных. Я же не про разбивку на бинари говорю.

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

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


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

                                                                      +1
                                                                      Речь идет лишь о «стимулирует» или «подталкивает», а не о жестких следствиях.

                                                                      Я точно также могу утверждать, что полирепы поощрают вас, к примеру, хранить фронт-енд и бэк-енд в разных репозиториях, и протокол между ними не генерить из общего IDL по соседству, а писать руками дважды (счастливой отладки при апдейте схемы).
                                                                      Вот не совсем. Скорее, если культура разработки высокая, то подталкивает нормально этот протокол версионировать. Что позволяет избежать отладки при апдейтах системы :)
                                                          0

                                                          Немного персонального опыта.
                                                          Работал и с монорепами в команде 8+ человек, работал и с полирепой в средней по размеру команде.


                                                          Имхо. Накладные расходы увеличиваются серьезно в полирепе. У нас есть makefile, который умеет инициализировать репозитории, подбрасывать симлинки на реальные инстансы кода вместо сабмодулей и много чего еще для работы. Кроме того это требует наличия метарепозитория (инфраструктурной репы), который умеет собирать все и деплоить в прод по кнопке. Все это требует вдумчивой проработки и внимания на поддержку.


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

                                                            +1
                                                            Проблема в том, что когда проблемы начинают себя проявлять, разделить монорепозиторий уже скорее всего не получится по техническим, но прежде всего по идеологическим причинам (это будет выглядеть революцией по сравнению с накручиванием нового тулинга вокруг старого подхода). Именно с этой проблемой я столкнулся в своей текущей компании — проблемы видят все, но считают, что бороться надо с помощью инструментов
                                                              0

                                                              Одна из задач разработчика — доказать, что такая революция нужна. Особенно, в случае, когда тут команда разработчиков.


                                                              А вообще, не могу не согласиться, что чаще происходит именно так.


                                                              P. S. Накладные расходы в начале примерно такие же. Особенно, если в команде есть джуны.

                                                            +1

                                                            Видел я один монореп на 2000+ разработчиков. Разумеется со своими внутренними доработками, странной документацией, занимательными багами и ограничениями при работе из под Windows (большинство сотрудников с маками).
                                                            Я дня два матерился прежде чем смог выкачать и собрать проект.
                                                            В общем, теперь у меня есть новый вопрос к работодателям на интервью.

                                                              0

                                                              Только вчера вечером задался вопросом, а Хабр вчера утром на него даёт ответ )))

                                                                0

                                                                Спасибо за перевод, но кажется, что исходное утверждение излишне категорично (или автор сознательно "вбросил"). Просто каждой задаче своё решение.
                                                                Монорепозиторий крупных продуктов (100-1000 разработчиков) вполне распространенное явление: ядра Windows и Linux, .NET Core (прадва, их два 2: CLR и FX, но деление относительно естественное), IntelliJ IDEA Community Edition. Chromium сидит на двух стульях (часть компонент типа V8 отдельно, но и оставшийся булыжник весьма большой). Так посмотреть, то из крупных продуктов, тех кто на git сидит (то есть JDK и Firefox на hg выпадают) — большинство сидят в монорепозиториях.
                                                                А почему?


                                                                1. Продукт единый и нет явных причин где-то строить границу (кроме объёма репы). Ну или граница есть, и это распадается на разные продукты.
                                                                2. Это позволяет перекраивать верхнеуровневую структуру продукта ("одним коммитом"). Причем важно, что не только структуру кода, но и структуру команд!
                                                                3. Это позволяет вносить связанные изменения одним коммитом. Да, все стремятся делать коммиты как можно компактнее, но они же должны быть еще и "атомарными". Если одно логическое изменение приходится делать в нескольких репозиториях, то обеспечение атомарности потом нужно дополнительно обеспечить (либо в "надрепозитории", либо в сборке и упровлении зависимостями)

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


                                                                НО! Если есть возможность раскидать продукт на слабозависимые репозитории, то, конечно, это надо сделать. В корпоративной среде пример — микросервисы, в OSS — Gnome и KDE. В этих случаях обычно зависимости и связи удобнее разрешать в сборке и поставке (не в subrtee/submodule)


                                                                ИМХО про subrtee/submodule

                                                                Я считаю, что механизм subrtee/submodule придаёт совершенно ненужную хрупкость репозиторию. Лучше задачу управления зависимостями отдавать отдельным сервисам: сборке, CI, CD.


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

                                                                  0
                                                                  CI, конечно, очень надёжная штука. Особенно, когда разрабатываешь на локальной машине десяток зависящих друг от друга модулей.
                                                                  0
                                                                  Это чем-то похоже на «единую ли базу знаний иметь для всего человечества или одну для каждого языка?»…

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

                                                                  Самое читаемое