Комментарии 14
Клонирование огромной монорепы к себе на локал тоже отдельная песня. Перед уходом ставишь git clone… и можно идти домой. К утру как раз склонируется.
Проектов в гите десятки (ядровые функции, система расчетов, модуль пластиковых карт, универсальный кассовый модуль и т.д. и т.п. — у каждой команды свой проект и это только бэк, а есть еще фронты, пега, SAP, WBI и черт знает что еще).
И в каждом проекте сотни репозиториев — на каждую функциональную единицу свой (например, отдельный по техвыписке, отдельный по учету валютных операций, отдельно по карточкам клиентов — их вообще несколько — физики, юрики...). И в каждом репозитории как минимум десяток (а может быть и сотня и более) объектов.
Свести все это в монорепу? Вы серьезно? Как там потом что-то найти можно будет?
Тут в пределах одной репы приходится папочную структуру делать чтобы разнести объекты по типам (например — таблицы отдельно, индексы отдельно, функционал отдельно и т.п...)
Зависимостей между разными функционалами у нас полно. Мы не считаем свою архитектуру строго микросервисной, предпочитаем использовать старый добрый термин API. Фактически достаточно близко к микросервисам. Все зависимости обеспечиваются пререквизитами которые проверяются на этапе установки патча в юнит (тут много платформенной специфики, фактически при сборке патча генерируется программа-инсталлятор куда включается проверка пререквизитов по таблице где регистрируются все установленные патчи и там же регистрация патча после успешной инсталляции).
Ну и интеграционное тестирование никто не отменял. Т.е. сначала компонентное, потом бизнес, потом интеграционное и нагрузочное. И только после этого внедрение на пром.
Свести все это в монорепу? Вы серьезно? Как там потом что-то найти можно будет?
Тут в пределах одной репы приходится папочную структуру делать чтобы разнести объекты по типам (например — таблицы отдельно, индексы отдельно, функционал отдельно и т.п...)
ну, раскидать по каталогам или раскидать по репам — это просто разные способы организации, иерархии, которые могут реализовать один и тот же уровень разделения...
ну, раскидать по каталогам или раскидать по репам — это просто разные способы организации, иерархии, которые могут реализовать один и тот же уровень разделения...
Это очень разные способы организации иерархии.
Когда в одной монорепе будет копошиться 10 человек и каждый со своими коммитами и PR, там быстро наступит ситуация когда сложно что-то разобрать.
У нас есть строгие правила ведения веток. feature, как только только она прошла компонентное тестирование и ушла на бизнес-тест, мержится в develop. Новые feature делаются только от develop и ниоткуда больше. Т.е. develop — это синхронизационная ветка.
develop мержится в мастер когда поставка ушла на прод. Т.е. мастер всегда отражает то, что стоит на проде. develop — то, что в бизнес-тесте и далее, но до прода еще не дошло.
В монорепе, где одновременно работает хотя бы 3-5 человек, поддерживать такой порядок замучаешься.
А раскидать по каталогам — это просто свое личное удобство, не более.
Вот сколько у вас всего репозиториев объеденено в монорепу?
У нас в гите 205 проектов И в каждом проекте… Да черт его знает. В нашем только несколько сотен репозиторииев.
И если все это в монорепу слить, то получим репу с десятками тысяч объектов, в которой одновременно работает более сотни человек. Как всем этим управлять и кто за всем этим будет следить?
Монорепа может и имеет какие-то преимущества на маленьких проектах, но на определенном этапе масштабирования вызовет очень большие проблемы организационного характера.
Я не адвокат монорепы, не знаю, с чего Вы это взяли ) Я наоборот согласен с тем, что инструменты — git и gitlab провоцируют скорее на создание все большего и большего количества микрорепозиториев (один репо — один компонент). И туда же концепция с форками. И необходимость тащить ещё интеграционные/инфраструктурные репо
И на самом деле то, что в монопереход все толкаются и мешают друг другу — ну, наверное, преувеличение. Хотя и вероятность конфликтов ниже, чем в куче мелких реп.
И на самом деле то, что в монопереход все толкаются и мешают друг другу — ну, наверное, преувеличение. Хотя и вероятность конфликтов ниже, чем в куче мелких реп.
О каких конфликтах речь?
На уровне зависимостей? Так это прежде всего вопросы правильной архитектуры, а не организации реп. Если каждый разработчик будет тащить все дерьмо из сети в проекты, ту без конфликтов никак.
С репой >1000 объектов просто неудобно работать. Даже нацти нужный объект из 1000 уже задача та еще.
Главное что непонятно — зачем? Все проблемы, описанные в статье решаются на совершенно ином уровне. Это все проблемы роста мелких команд, берущихся за проект больший, чем они могут осмыслить
Эти проблемы решаются крупными компаниями — Microsoft доработало git, чтобы скачивать только часть репозитория. Яндекс изобрел свой репозиторий Arc… В общем, нужно помнить, что ты не Гуголь и не обязательно, что механизмы, которые могут позволить крупные технологические компании, могут быть смапплены на мелочь вроде Юлы...
Если хочется, например, обновить библиотеку, чтобы она обновилась во всех сервисах, нужно подтянуть новую версию в каждом репозитории. Это лишние телодвижения, которых можно избежать. И монорепо позволяет это сделать.
Спорный момент.
Проблемы остаются те же, ибо изначально было проведено четкое неравенство между монорепо и монолит, а значит каждый проект вашего монорепо даже если и имеет лишь одну общую ссылку на условный адаптер Redis — то код всех проектов по-отдельности завязан на эту версию. И соответственно при изменении интерфейсов работы с библиотекой придется гулять по всему монорепо в поисках точек взаимодействия и править код коллег, ведь он может даже не скомпилиться, и в таком случае придется вникать в их код, чтобы внести корректную правку, и в итоге ты все равно контактируешь с каждым из них, чтобы вместе правильно обновить версию в конкретно их проекте.
Или что хуже — обновляешь всё сам, но не учитываешь какие-либо особенности "чужого" проекта и коллеги узнают о твоём "обновлении" сильно позже.
Он не может сам сориентироваться по поиску через GitLab/GitHub
Открываете корень всех проектов и листаете и ищите. Ни чем не отличается от моно репозитория. Зато когда у вас репозиторий на сервис то локально вы можете их группировать или называть как хотите. Плюс не надо тянуть 100500 сервисов над которыми вы вообще не работаете и знать не надо что там.
Ведь через Go.mod это не так просто сделать.
Выкиньте Го :) и сразу куча проблем уйдет.
Если хочется, например, обновить библиотеку, чтобы она обновилась во всех сервисах
А зачем это? Микросервис это как раз о том, что можно работать и менять только один сервис и остальным будет все равно что там внутри. К примеру, в новом сервиса хорошо заходят клиентская инвалидация с Редис 6, но это новая версия библиотеки в которой есть изменения по АПИ и это значит что фиг я протащу такое изменение в мой сервис и отдельный редис, потому что у остальных есть дела поважнее чем переводить свои сервисы на новую версию библиотеки.
Ревью сможет заняться один разработчик, у которого будет полный контекст по задаче.
Какая разница как вы храните сервисы, главное тут вот этот разработчик. И он как может быть так и не быть, без разницы монорепо или нет.
В нем вы будете видеть, что делают другие команды, или хотя бы замечать появляющиеся обновления
Я не всегда успеваю понимать что происходит в своей команде, а мониторить всю компанию это надо тратить все время и не писать ни строчки кода.
Наверное, каждый мечтает о том, чтобы было возможно локально поднимать все окружение по щелчку пальцев.
А вот это самая большая проблема — если у вас возникает такая ситуация то нет у вас микросервисов, а есть распределенный монолит. При правильной архитектуре, локально вам нужен только один ваш сервис и его состояние. А то потом вы упретесь что надо поднять 100 сервисов, а с ними еще 40 Редисов, 30 Постгресов и тд что не реально на одной локальной машине. И если это возможно все поднять на одной машине и вам такое надо то зачем микросервисы? Сделайте монолит и сразу кучу проблем уйдет :)
А зачем это? Микросервис это как раз о том, что можно работать и менять только один сервис и остальным будет все равно что там внутри.
Вот это ключевой момент. Главное — сохранение интерфейса. А внутреннюю логику можно (и иногда приходится) править. И это хорошо и правильно. Так и должно быть. Изменились требования — поправили под них логику работы одного сервиса и вся система стала работать по новым требованиям.
А вот это самая большая проблема — если у вас возникает такая ситуация то нет у вас микросервисов, а есть распределенный монолит. При правильной архитектуре, локально вам нужен только один ваш сервис и его состояние. А то потом вы упретесь что надо поднять 100 сервисов, а с ними еще 40 Редисов, 30 Постгресов и тд что не реально на одной локальной машине. И если это возможно все поднять на одной машине и вам такое надо то зачем микросервисы? Сделайте монолит и сразу кучу проблем уйдет :)
Вот этой проблемы у нас нет в силу особенностей работы. Пишем под AS/400 и все поставки тестируются на отдельном тестовом сервере. Т.е. разработка — гит — сборка из гита в артифактори — установка из артифактори на тестовый сервер — тестирвание — продвижение дальше до прома.
Тестовый сервер от прома отличается количеством данных (их там меньше) и тем, что данные на тесте деперсонифицированы. На полной копии прома идет только нагрузочное тестирование, но это отдельный сервер.
Наверное, и в других ситуациях можно организовать что-то подобное. Тогда не потребуется разворачивать всю среду на локале. И тесты будут более объективными т.к. проходить будут в близком к прому окружении — нестыковки с другими патчами там сразу вылазят.
Очень спорная аргументация. А самое прекрасное — это когда есть разработка на аутсорсе, которая не должна видеть весь монорепо, а эти ребята разрабатывают какой-то изолированный сервис… И приходится изобретать механизмы переливки.
Я уж не говорю, что Gitlab не любит монорепы от слова совсем…
Ну, и типичный кейс, когда комменты интереснее статьи
Монорепо: жизнь до и после