Монорепозиторий VS Мультирепозиторий | GoGetPodcast №6

[@mmkamron]

Классный подкаст, спасибо

[@2TheVan]

Не работал с полноценной монорепой, но выскажусь) 1. Одинаковые рамки и формат кода - было верно сказано: «кодстайл может поддерживаться злобными едиными линтерами и общими кодстайл соглашениями» - не увидел разницы между моно- и мульти- репами. 2. Работа с общим кодом - считаю скорее злом, уже несколько получалось что багу либы коллеги использовали в качестве фичи (например для специфичной обработки). В монорепе не получится сразу узнать, что чей-то функционал стал недоступен (особенно если этот функционал используется раз в месяц, деплоится сервис раз в полгода, не покрыт нормально метриками и е2е тестами). Коллегам придётся долго бегать и выяснять кто/как/зачем/где менял код. 3. Устаревшие зависимости при мультерепе решаются проверкой зависимостей в CI-CD. Не обновлена либа, хотя предупреждали? Значит пайплайн по выкате закрыт. 4. Поднимается свой прокси: выкачать старые, экзотические или пакеты с уязвимостями технически невозможно.

[@yukas1ngas]

По 2: а коллеги git log не могут набрать?

[@2TheVan]

@@yukas1ngas Пока 10-20 разрабов - можно. Когда 100+ разрабов - каша абсолютно нечитабельная получится.

[@yukas1ngas]

@@2TheVan Как же Линус Торвальд то справляется? А Вы git log [filename] пробовали?

[@a98cb985]

Спасибо за выпуски, очень познавательно

[@pawelf.7568]

Я позволю себе привести банальнейший пример из своей практике как аргумент за мультирепы Это то, о чём Лёша говорил про конфликты в ветках Есть некий разросшийся легаси сервис на го. Хочется его как-то отрефакторить. Для начала например - заменить стандартный логгер на zap. Такой рефакторинг - он довольно тупой и тривиальный, но затрагивает чуть ли не каждый исходный файл. В этом же спринте пилятся срочные прод задачи. И вот в конце спринта выясняется что конфликтов на столько много, что нужно задачу про логгирование переносить в след. спринт в угоду более приоритетным продуктовым. Если что, похожая ситуация с метриками, выпиливанием глобалных переменных и т.п. улучшениям у меня регулярно воспроизводилась чуть ли не каждый спринт какое-то время

[@Levelord92]

Николай, сделайте пожалуйста видео, посвящённое system design.

[@ViktorPolyakov15]

А какие тулзы для монорепы есть для Гошки? Вот для NodeJS есть NX и Lerna, а для Гошки?

[@pSSSix]

Привет. На самом деле много с чем бы поаплодировал в данном виде в пользу мультирепозиториев, но так как у меня не было Накой возможности не буду холиварить. У монорепозиториев вижу много ограничений которые они вносят и многое, что о них было сказано: не надо отслеживать зависимости в других репозиториях, несовместимости кодовой базы библиотек, решаются другими путями, например симантическим версионированием. Просто надо знать какие подходы и для чего. Мое личное мнение, что люди используют монорепозитории из-за страхов построить здоровые процессы разработки и углубиться в практики которые применяются, обычно, для решения той или иной проблемы. Просили написать того, у кого были хорошо отстроенные процессы тестирования и тесы решали проблемы стабильности. Так вот, на предыдущей работе я был CTO, процессы разработки были построены вокруг TDD и тесты решали проблемы стабильности, вплоть до CD и отмены запрета деалоиться в пятницу. Писали мы платежный сервис, так вот думайте… По факту тесты либо работают, либо нет, не могут работать на 70%. В общем подумайте)))

[@alexandriulin9640]

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

[@eligolin9947]

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

[@eligolin9947]

Здесь надо чуть поподробней на счёт версации компонент. Моё личное мнение что версия компоненты должна быть привязана к комиту на основе которого производилась сборка компоненты. Это является для меня обязательным правилом в не зависимости от моно либо мульти репо подходе. А теперь надо задать вопрос: Есть ли у вас в архитектуре компоненты самодостаточны и инкапсулированны настолько, что они живут своей жизнью и развертываются в не зависимости от других? Если ответ да, то очень желательно чтоб у них была своя версия а сделать это в монорепо не возможно (учитывая моё первое правило привязанности версии к гит комиту).

[@nikolay_tuzov]

Приходи в наш чатик обсуждать подобные вещи, там удобней (ссылка в описании)