Никто не утверждает, что в репозитории должен лежать ровно один микросервис и все. В мою бытность использования полирепозиториев мы прекрасно складывали семейство тесно связанных микросервисов в один репозиторий.
Ну так maven делает такой резолв версий зависимостей уже примерно лет 100. Причем политику можно задать, или для конкретной библиотеки разрулить руками и зафиксировать версию.
Ну есть ещё софт, который работает 5*8 и обновляется по выходным с даунтаймом.
Это не отменяет того, что я написал, что специфика вашего деплоя такова, что не накладывает на это ограничений. Что же, вам повезло, для вас этот недостаток неактуален.
А как вы в монорепе сделаете, чтобы А и Б зависели от разных версий Ц? Точнее, вы сделаете, только непонятно, чем тут монорепозиторий помогает? Будет ровно такой же конфликт транзитивных зависимостей, который нужно решать.
Тем, что он вам не позволит в библиотеках А и Б завязаться на разные версии Ц? Да позволит, куда денется. И точно также вы узнаете об этом в самый последний момент.
Проблема в том, что когда проблемы начинают себя проявлять, разделить монорепозиторий уже скорее всего не получится по техническим, но прежде всего по идеологическим причинам (это будет выглядеть революцией по сравнению с накручиванием нового тулинга вокруг старого подхода). Именно с этой проблемой я столкнулся в своей текущей компании — проблемы видят все, но считают, что бороться надо с помощью инструментов
> Это зависит не от количества людей, а от сложности проекта.
И от количества людей тоже (мало людей не смогут нагенерировать поток коммитов и создать проблемный размер для репозитория), так что если 2-3 человека, то основные проблемы монорепозитория не очень проявляют себя.
> Одно из преимуществ, которое мне нравится — подмодули заставляют тебя так декомпозировать код,
Это указано в статье, тоже считаю это преимуществом
> Ещё одно преимещуство — это пакетирование.
вот тут не вижу взаимосвязи с моно- или полирепозиторием, мы в своем монорепозитории собираем отдельные пакеты для каждого микросервиса под разные платформы, работало и на maven, работает и на bazel
> Ещё одно преимущество — можно делать глобальный рефакторинг не по всему проекту сразу, а частями через подмодули
ну прямо скажем, в монорепозитории тоже так можно. Даже более того, (об этом сказано в статье) другого варианта у вас нет даже в монорепозитории из-за неатомарности деплоя.
А как вы собираетесь деплоить эти связанные изменения?
Я бы сказал, что если у вас есть сильная связь между репозитоиями, вы неправильно определили границы.
Если все же границы определены верно, то не нужно писать этот код вместе — добавьте изменения в первый репозиторий, задеплойте его, потом добавьте во второй — задеплойте его.
Именно это и говорится в статье — есть ровно 20+- компаний в мире, которые умеют в монорепо. Это гугл, фейсбук, твиттер, яндекс, может быть, кто-то еще.
Остальным не надо даже пытаться, т.к. правильных инструментов у вас нет, как и ресурсов на их создание.
Для решения такой проблемы монорепощиторщики придумали свой тулинг :) называется мерджбот
Например prow от Goggle bentheelder.io/posts/prow или сервис mergify.io
Проблема со всеми этими проектами описана в статье.
Все они обладают очень сильной привязкой к специфике кодовой базы разработчика. Их просто невероятно сложно начать использовать. Говорю это, как человек, переведший монорепозиторий с мавена на bazel
По сути автор говорит именно об этом, но суть в том, что подход с монорепозиторием на определенном масштабе начинает добавлять проблем с производительностью VCS и не только, которые нужно как-то решать. Гугл может себе позволить иметь сотни разработчиков, работающих годами над этими проблемами. Может ли ваша компания?
Частично да, но иногда, к сожалению, нужно протестировать интеграционные сценарии. А что того хуже, иногда их нужно ещё и продебажить. Так что хорошо иметь возможность запустить хотя бы часть системы (несколько сервисов, в зависимости от воспроизводимого сценария) локально из IDE в дебаг режиме
Ну в статье и говорится не об одном разработчике, а о проекте с 100+ разработчиками.
Могу сказать по своему опыту, про темы совсем невыдуманные. Особенно в части того, что некоторые компании бездумно копируют практики.
В данный момент у нас 200+ инженеров работают над монорепозиторием. Более 100 коммитов в день, билд на CI занимает около 40 минут. Клонирование репозитория с Гитхаба (учитывая поганый Австралийский интернет) занимает больше 10 минут.
Я уж не говорю про индекс в Идее
Проблема с сабмодули, что они ссылаются на конкретный коммит. Таким образом, держать такой репозиторий в актуальном состоянии довольно трудно. Можно, конечно, автоматизировать, чтобы всегда вытягивать, например, свежие релизные версии… Но не очень понятно, какую проблему это решает. Если хочется запускать полностью всю систему локально, то проще залить артифакты в registry/bintray/куда-то ещё и точно также запустить docker-compose
Это тоже хороший аргумент, хотя я бы не стал внешним подрядчикам давать доступ в любой репозиторий, пусть заведут отдельный и оттуда делают патчи.
Это не отменяет того, что я написал, что специфика вашего деплоя такова, что не накладывает на это ограничений. Что же, вам повезло, для вас этот недостаток неактуален.
Тем, что он вам не позволит в библиотеках А и Б завязаться на разные версии Ц? Да позволит, куда денется. И точно также вы узнаете об этом в самый последний момент.
И от количества людей тоже (мало людей не смогут нагенерировать поток коммитов и создать проблемный размер для репозитория), так что если 2-3 человека, то основные проблемы монорепозитория не очень проявляют себя.
> Одно из преимуществ, которое мне нравится — подмодули заставляют тебя так декомпозировать код,
Это указано в статье, тоже считаю это преимуществом
> Ещё одно преимещуство — это пакетирование.
вот тут не вижу взаимосвязи с моно- или полирепозиторием, мы в своем монорепозитории собираем отдельные пакеты для каждого микросервиса под разные платформы, работало и на maven, работает и на bazel
> Ещё одно преимущество — можно делать глобальный рефакторинг не по всему проекту сразу, а частями через подмодули
ну прямо скажем, в монорепозитории тоже так можно. Даже более того, (об этом сказано в статье) другого варианта у вас нет даже в монорепозитории из-за неатомарности деплоя.
Я бы сказал, что если у вас есть сильная связь между репозитоиями, вы неправильно определили границы.
Если все же границы определены верно, то не нужно писать этот код вместе — добавьте изменения в первый репозиторий, задеплойте его, потом добавьте во второй — задеплойте его.
Остальным не надо даже пытаться, т.к. правильных инструментов у вас нет, как и ресурсов на их создание.
Это не ноды одного кластера, а независимые подсистемы
В подробности вдаваться не буду, просто поверьте на слово ;)
Например prow от Goggle bentheelder.io/posts/prow или сервис mergify.io
Все они обладают очень сильной привязкой к специфике кодовой базы разработчика. Их просто невероятно сложно начать использовать. Говорю это, как человек, переведший монорепозиторий с мавена на bazel
Это к вопросу о том, где хранятся исходники Windows
Вы абсолютно правы :)
Частично да, но иногда, к сожалению, нужно протестировать интеграционные сценарии. А что того хуже, иногда их нужно ещё и продебажить. Так что хорошо иметь возможность запустить хотя бы часть системы (несколько сервисов, в зависимости от воспроизводимого сценария) локально из IDE в дебаг режиме
Ну в статье и говорится не об одном разработчике, а о проекте с 100+ разработчиками.
Могу сказать по своему опыту, про темы совсем невыдуманные. Особенно в части того, что некоторые компании бездумно копируют практики.
В данный момент у нас 200+ инженеров работают над монорепозиторием. Более 100 коммитов в день, билд на CI занимает около 40 минут. Клонирование репозитория с Гитхаба (учитывая поганый Австралийский интернет) занимает больше 10 минут.
Я уж не говорю про индекс в Идее
Проблема с сабмодули, что они ссылаются на конкретный коммит. Таким образом, держать такой репозиторий в актуальном состоянии довольно трудно. Можно, конечно, автоматизировать, чтобы всегда вытягивать, например, свежие релизные версии… Но не очень понятно, какую проблему это решает. Если хочется запускать полностью всю систему локально, то проще залить артифакты в registry/bintray/куда-то ещё и точно также запустить docker-compose