Микросервисы и Git репозитории

Как вы предпочитаете работать с таким количеством микросервисных репозиториев одновременно?

Если это микросервисы, каждый в своём репе, то никаких контактов между ними на уровне исходников вообще не должно быть. Каждый проект разрабатывается отдельно, пакуется в джарник, джарники версионируются и складываются в Maven-репу, из которой собирается контейнер.

Поэтому вопрос некорректен.

Если работаешь в идее то лучше заведи отдельный проект с самбодулями, иначе идея со своей инопланетной организацией воркспейса тебе мозг съест.

Какими аргументами можно заставить DevOps обновить систему с более новым Git?

Китайские хакеры, без шуток: https://www.wired.com/story/china-hacking-windows-zero-day-ios-watering-hole-... и это только малая доля!

Активизировались в последнее время эти нехорошие люди, «хакерствуют» во зло. Вначале «оффтопик», потом «тыблоко», а там и на товарищей со старым, незащищённым ПО.

Как вы предпочитаете работать с таким количеством микросервисных репозиториев одновременно?

В Gitlab есть т.н. группы проектов, смотрите в эту сторону. Сам же код должен быти изолирован друг от друга «во избежание», так сказать.

Есть общие библиотеки, исходники которых тоже живут в отдельных репозиториях. Иногда просто хочется посмотреть код другого микросервиса к которому первый обращается через REST. Делать git checkout <branch> в нескольких репозиториях по отдельности неудобно. Иногда изменения затрагиюват несколько микросервисов или микросервис и одну - две библиотеки и опять возникает необходимость дублировать определённые действия в нескольких репозиториях.

На сколько хорошо IntelliJ работает с git сабмодулями?

Делать git checkout в нескольких репозиториях по отдельности неудобно

Сабмодули никак этому не помогают, только усложняют общую структуру.

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

Для таких вещей есть ide, которые умеют работать с множеством репозиториев, или cli тоже многие настраивают под себя.

Делать git checkout в нескольких репозиториях по отдельности неудобно

Это ещё почему? Пишется скрипт на питоне и делается чекаут хоть в 15 репах, потом обратно на мастер - без проблем. Репозитории лучше держать в малой связности, сабмодули редко где хороши, в основном как внутренние либы проекта, разрабатываемые независимо/другими людьми, и то, почти всегда можно и без сабмодулей сделать всё то же самое, но да - скрипты придётся пописать для всяких параллельных

git checkout -

Про связь между исходным кодом уже написали (это противоречит идее микросервисов), поэтому это должно быть просто 20 независимых гит репозиториев.

ДевОпс должен решить задачу не разработки, а раскатки готового решения в первую очередь. Я бы сделал следующее:

1. Проекты должны быть организованы одинаково (схема сборки, куда публикуются артефакты, как они называются и версионируются)
2. Раскатка и запуск сервисов также должна быть унифицирована (одинаковые виртуалки, одинаковая схема работы с ними и прочее)

P.S. 20 - это не много. Много - это хотя бы 100. Представьте, что у вас 100 микросервисов и организуйте работу исходя из этого. Иначе, когда количество сервисов возрастет, вы не сможете перестроиться.

На сколько хорошо IntelliJ работает с git сабмодулями?

Хорошо работает.

Рекомендую монорепозиторий. Решает все проблемы.

И добавляет новых:-)

Про связь между исходным кодом уже написали (это противоречит идее микросервисов), поэтому это должно быть просто 20 независимых гит репозиториев.

Они и так совершенно независимые.

subrepo шикарен, остальное может решаться через хуки

Рекомендую монорепозиторий. Решает все проблемы.

Совершенно неприемлемо.

Это ещё почему? Пишется скрипт на питоне и делается чекаут хоть в 15 репах, потом обратно на мастер - без проблем.

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

git checkout -

Давно знаю про это. Предлагаете использовать для написания отката в случае невозможности завершить чекаут во всех репах? Нехороший это путь.

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

Они разрабатываются разными группами разработчиков.

subrepo шикарен, остальное может решаться через хуки

К сожалению у нас git 1.8.3.1, а там нужен новее:

Note: git-subrepo needs a git version (> 2.7) that supports worktree:s.

Это неважно.

Ну, вот у нас ровно так и работает. Овер 20 независимых репозиториев. Общие библиотеки лежат отдельно. Не понимаю, какую проблему ты хочешь решить.

А в чём проблема посмотреть?

У нас код вообще в гитхабе лежит, чтобы смотреть — не нужно даже чекаутить. Но даже если у вас не так, держать у себя более-менее свежий мастер всего — хорошая идея.

Смотреть в IDE.

Ну, открой и посмотри. Или у тебя мастер десятилетней давности, и ты в нём чейнджи делаешь? Ну дык ССЗБ.

Причём тут мастер вообще? В разных бранчах бывает необходимость смотреть. Сразу несколько реп в эти бранчи переключать. У части реп этих других бранчей может и не быть вовсе. Бранчи могут выходить необязательно из мастера.

В разных бранчах бывает необходимость смотреть.

Э-э-э… зачем?

Бранчи могут выходить необязательно из мастера.

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

Э-э-э… зачем?

Затем что разные версии живут в разных бранчах.

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

Что-то мне кажется вы некомпетентны.

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

Ту версию. Продакшенов несколько, с разными версиями.

О боже.

Зачем с ними работать одновременно? Вы в курсе что микросервисы для того и придумали чтобы работать и ними независимо?

Не разрабатывать их независимо, а чтобы они работали независимо. Это не одно и то же.

Нет, именно разрабатывать.

Долбались всеми доступными способами. Все эти git subxxx не решают и толики проблем межвидового скрещивания.

Поэтому поместили все микросервисы всего отдела в монореп. Там каталоги с разными проектами, плюс система сборки независимых связок проекта (артефакты в контексте bamboo).

То есть даже смотреть код другого микросервиса, к которому обращается твой микросервир, нельзя принципиально? :-))

У вас наверное небольшой отдел, иначе вы бы давно застрелились во время очередного конфликта при мердже.

Таки монорепа – единственно работающее решение.

иначе вы бы давно застрелились

Расскажи это Google. Да, там всё моно, включая ядро лялиха и вообще всё, что они делают.

То есть даже смотреть код другого микросервиса

Если это микро – то не по-понятиям. Там даже язык может быть марсианский.

Если это микро-монолит – то кто спросит?

Расскажи это Google.

Google использует свой repo как раз чтобы не использовать монореп.

Если это микро – то не по-понятиям.

Странные у тебя понятия.

Ты вроде совсем не понял, что я тебе пытался сказать.

В мире (псевдо-)микосервисов, это абсолютно независимые сущности, написанные нередко даже на разных языках.

Т.ч. о каком code-share (окромя самых базовых вещей) может идти речь?

Я конечно (ещё) в гугле не работал, но у меня достаточно коллег, которые там работали.

Так вот, то, что ты привёл – это не то что используется внутри.

На самом деле там всё сложно. Репа там на много терабайт. Всю ещё вычекнуть ты не сможешь. И там даже не git. По-этому используется что-то вроде fuse-view на твой sub-tree. С драконовой code-review, которая over90% AI. То что попало в «master» – это live.

На самом деле там всё сложно. Репа там на много терабайт. Всю ещё вычекнуть ты не сможешь. И там даже не git. По-этому используется что-то вроде fuse-view на твой sub-tree. С драконовой code-review, которая over90% AI. То что попало в «master» – это live.

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

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

А публика вместо того чтобы учиться на гугловых ошибках испытывает вау-эффект и ломится повторить, потому что они тоже не хотят работать по делу, а хотят плодить монстров, о которых придется потом писать исследовательские статьи. Это же намного интереснее.

Знаешь, компании с многолетним стажем, и составом почти поголовно из PhD, я доверяю больше, чем кукаретикам с ЛОРа.

зря мы в это вообще вляпались

Скорее это единственное, что скалируется.

Знаешь, компании с многолетним стажем, и составом почти поголовно из PhD…

Собственно, ЧТД.

Скорее это единственное, что скалируется.

Масштабироваться через централизацию - это тупиковый путь. Это как масштабироваться в сторону суперкомпьютеров в век облаков.

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

А может всё же стоит прислушаться к опыту впереди-идущих? Я понимаю, что вы все в тельняжках и всё такое прочее … но всё же?

Облако – это всего лишь чей-то чужой компьютер. (И в частности их конфигурация в той же присловутой репе.)

С чего ты решил что они - впереди?

Монорепо в гугле создавался, когда не было Гита и Github и других моделей разработки. На тот момент кому-то показалось что это осмысленное решение. Но с тех пор много что изменилось. И понятно что там накопилось legacy-костылей. которые не позволяют гуглу что-то в этом плане менять, даже если хочется.

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

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

При этом если взять положительную часть опыта: а именно понять что набор независимых реп стОит покрыть интеграционными тестами, то у тебя есть готовые стандартные инструменты для этого, не требующие инвестирования в них ни 10-ти лет разработки, ни департамента из 1000 человек.

У нас 4 человека. У нас свой потому что на С. Рядом Скаловики с монорепом на 50 человек. Пока не повесились.

Нас 16. Начинали с солянки реп (18 микро-монолитов), когда нас только 4-ро было. Четвёртый год уже всё в моно. Полёт чудесный. До этого только тр***лись.

Можно.