Не работал с полноценной монорепой, но выскажусь) 1. Одинаковые рамки и формат кода - было верно сказано: «кодстайл может поддерживаться злобными едиными линтерами и общими кодстайл соглашениями» - не увидел разницы между моно- и мульти- репами. 2. Работа с общим кодом - считаю скорее злом, уже несколько получалось что багу либы коллеги использовали в качестве фичи (например для специфичной обработки). В монорепе не получится сразу узнать, что чей-то функционал стал недоступен (особенно если этот функционал используется раз в месяц, деплоится сервис раз в полгода, не покрыт нормально метриками и е2е тестами). Коллегам придётся долго бегать и выяснять кто/как/зачем/где менял код. 3. Устаревшие зависимости при мультерепе решаются проверкой зависимостей в CI-CD. Не обновлена либа, хотя предупреждали? Значит пайплайн по выкате закрыт. 4. Поднимается свой прокси: выкачать старые, экзотические или пакеты с уязвимостями технически невозможно.
Я позволю себе привести банальнейший пример из своей практике как аргумент за мультирепы Это то, о чём Лёша говорил про конфликты в ветках Есть некий разросшийся легаси сервис на го. Хочется его как-то отрефакторить. Для начала например - заменить стандартный логгер на zap. Такой рефакторинг - он довольно тупой и тривиальный, но затрагивает чуть ли не каждый исходный файл. В этом же спринте пилятся срочные прод задачи. И вот в конце спринта выясняется что конфликтов на столько много, что нужно задачу про логгирование переносить в след. спринт в угоду более приоритетным продуктовым. Если что, похожая ситуация с метриками, выпиливанием глобалных переменных и т.п. улучшениям у меня регулярно воспроизводилась чуть ли не каждый спринт какое-то время
Привет. На самом деле много с чем бы поаплодировал в данном виде в пользу мультирепозиториев, но так как у меня не было Накой возможности не буду холиварить. У монорепозиториев вижу много ограничений которые они вносят и многое, что о них было сказано: не надо отслеживать зависимости в других репозиториях, несовместимости кодовой базы библиотек, решаются другими путями, например симантическим версионированием. Просто надо знать какие подходы и для чего. Мое личное мнение, что люди используют монорепозитории из-за страхов построить здоровые процессы разработки и углубиться в практики которые применяются, обычно, для решения той или иной проблемы. Просили написать того, у кого были хорошо отстроенные процессы тестирования и тесы решали проблемы стабильности. Так вот, на предыдущей работе я был CTO, процессы разработки были построены вокруг TDD и тесты решали проблемы стабильности, вплоть до CD и отмены запрета деалоиться в пятницу. Писали мы платежный сервис, так вот думайте… По факту тесты либо работают, либо нет, не могут работать на 70%. В общем подумайте)))
Соглашусь что моно-репо не означает монолит но реальность она обратная в это случаи. Если речь идёт о дистрибутивной облачной архитектуре которая так и проектируется изначально, то естественная рефлексия команды создать отдельный репозиторий под каждую компоненту.
Здесь надо чуть поподробней на счёт версации компонент. Моё личное мнение что версия компоненты должна быть привязана к комиту на основе которого производилась сборка компоненты. Это является для меня обязательным правилом в не зависимости от моно либо мульти репо подходе. А теперь надо задать вопрос: Есть ли у вас в архитектуре компоненты самодостаточны и инкапсулированны настолько, что они живут своей жизнью и развертываются в не зависимости от других? Если ответ да, то очень желательно чтоб у них была своя версия а сделать это в монорепо не возможно (учитывая моё первое правило привязанности версии к гит комиту).
Классный подкаст, спасибо
Спасибо за выпуски, очень познавательно
Не работал с полноценной монорепой, но выскажусь)
1. Одинаковые рамки и формат кода - было верно сказано: «кодстайл может поддерживаться злобными едиными линтерами и общими кодстайл соглашениями» - не увидел разницы между моно- и мульти- репами.
2. Работа с общим кодом - считаю скорее злом, уже несколько получалось что багу либы коллеги использовали в качестве фичи (например для специфичной обработки).
В монорепе не получится сразу узнать, что чей-то функционал стал недоступен (особенно если этот функционал используется раз в месяц, деплоится сервис раз в полгода, не покрыт нормально метриками и е2е тестами). Коллегам придётся долго бегать и выяснять кто/как/зачем/где менял код.
3. Устаревшие зависимости при мультерепе решаются проверкой зависимостей в CI-CD.
Не обновлена либа, хотя предупреждали? Значит пайплайн по выкате закрыт.
4. Поднимается свой прокси: выкачать старые, экзотические или пакеты с уязвимостями технически невозможно.
По 2: а коллеги git log не могут набрать?
@@yukas1ngas Пока 10-20 разрабов - можно.
Когда 100+ разрабов - каша абсолютно нечитабельная получится.
@@2TheVan Как же Линус Торвальд то справляется?
А Вы git log [filename] пробовали?
Николай, сделайте пожалуйста видео, посвящённое system design.
А какие тулзы для монорепы есть для Гошки? Вот для NodeJS есть NX и Lerna, а для Гошки?
Nx не только для js)
Я позволю себе привести банальнейший пример из своей практике как аргумент за мультирепы
Это то, о чём Лёша говорил про конфликты в ветках
Есть некий разросшийся легаси сервис на го. Хочется его как-то отрефакторить. Для начала например - заменить стандартный логгер на zap. Такой рефакторинг - он довольно тупой и тривиальный, но затрагивает чуть ли не каждый исходный файл. В этом же спринте пилятся срочные прод задачи. И вот в конце спринта выясняется что конфликтов на столько много, что нужно задачу про логгирование переносить в след. спринт в угоду более приоритетным продуктовым.
Если что, похожая ситуация с метриками, выпиливанием глобалных переменных и т.п. улучшениям у меня регулярно воспроизводилась чуть ли не каждый спринт какое-то время
Всем привет, кто может поделится ссылкой на монорепу которую можно былобы взять за пример.
Привет. На самом деле много с чем бы поаплодировал в данном виде в пользу мультирепозиториев, но так как у меня не было Накой возможности не буду холиварить. У монорепозиториев вижу много ограничений которые они вносят и многое, что о них было сказано: не надо отслеживать зависимости в других репозиториях, несовместимости кодовой базы библиотек, решаются другими путями, например симантическим версионированием. Просто надо знать какие подходы и для чего. Мое личное мнение, что люди используют монорепозитории из-за страхов построить здоровые процессы разработки и углубиться в практики которые применяются, обычно, для решения той или иной проблемы.
Просили написать того, у кого были хорошо отстроенные процессы тестирования и тесы решали проблемы стабильности. Так вот, на предыдущей работе я был CTO, процессы разработки были построены вокруг TDD и тесты решали проблемы стабильности, вплоть до CD и отмены запрета деалоиться в пятницу. Писали мы платежный сервис, так вот думайте… По факту тесты либо работают, либо нет, не могут работать на 70%.
В общем подумайте)))
Соглашусь что моно-репо не означает монолит но реальность она обратная в это случаи. Если речь идёт о дистрибутивной облачной архитектуре которая так и проектируется изначально, то естественная рефлексия команды создать отдельный репозиторий под каждую компоненту.
Здесь надо чуть поподробней на счёт версации компонент.
Моё личное мнение что версия компоненты должна быть привязана к комиту на основе которого производилась сборка компоненты. Это является для меня обязательным правилом в не зависимости от моно либо мульти репо подходе.
А теперь надо задать вопрос: Есть ли у вас в архитектуре компоненты самодостаточны и инкапсулированны настолько, что они живут своей жизнью и развертываются в не зависимости от других?
Если ответ да, то очень желательно чтоб у них была своя версия а сделать это в монорепо не возможно (учитывая моё первое правило привязанности версии к гит комиту).
Приходи в наш чатик обсуждать подобные вещи, там удобней (ссылка в описании)