Версионнинг очень больших баз кода
От: Barbar1an Украина  
Дата: 18.04.22 15:49
Оценка:
как вообще это делается?

ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты
как такое версионится?
ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули?
а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re: Версионнинг очень больших баз кода
От: bnk СССР http://unmanagedvisio.com/
Дата: 18.04.22 16:54
Оценка: +3
Здравствуйте, Barbar1an, Вы писали:

B>как вообще это делается?


B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты

B>как такое версионится?

Честно говоря, я не очень верю что один и тот же код может развиваться двумя разными командами.
То есть на практике я такого не видел, но возможно есть варианты, да и я вообще мало чего видел.
Но на мой взгляд, обычно код контролируется одной командой, "общий код" = "бесхозный код" — не должно такого быть imho.

На базе гита внесение нужной правки в "чужой" код можно организовать pull request например из другой команды,
такой механизм любая более-менее современная система управления кодом предоставит.

Если код оформлен в виде библиотеки, ну там nuget/npm модуля это уже другой случай, все равно что использовать 3rd-party библиотеку.
То есть, имеем тогда общий код в виде отдельного "продукта" и его собственного репозитория.

Но тут еще зависит от используемой платформы и какого рода "модули" она поддерживает.
Я в том смысле, многие поддерживают локальные (внутри компании) репозитории для модулей типа npm или там nuget.
Re: Версионнинг очень больших баз кода
От: Kernan Ниоткуда https://rsdn.ru/forum/flame.politics/
Дата: 18.04.22 18:01
Оценка: +1
Здравствуйте, Barbar1an, Вы писали:

B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули?

Можно выносить в отдельные либы и через пакетный менеджер вроде конана подтягивать как зависимость. Проблема тут очевидна, довольно длительный путь интеграции изменений в общую часть т.к. надо со всеми договориться и пройти все тесты, потом миграция с тестированием новой версии либы во все продукты. Если компания очень крупная, то сможет себе позволить, наверное. С CI/DI будет полегче, но оно не панацея конечно же.
Sic luceat lux!
Re: Версионнинг очень больших баз кода
От: Reset  
Дата: 18.04.22 18:49
Оценка:
B>как вообще это делается?

B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты

B>как такое версионится?
B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули?
B>а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить

В реальности: IMHO, либо нормальный пакетный менеджер, если все пишется на одном языке. Либо система сборки, реализующая функциональность пакетного менеджера. Плюс некая политика обратной совместимости, чтобы в одном exe'шнике не было 10-ти версий одной бибилиотеки с учетом транзитивных зависимостей.

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

В идеале: Однако, единственная работающая идеально схема — это когда каждая новая версия библиотеки обеспечивает вплоть до бинарной совместимости со всеми предыдущими версиями, пока они используются. Т.е. что-то типа libc/libstdc++, когда все символы версионированы и новая функциональность выпускается с символами под новыми версиями. При этом в каждой сборке присутствуют все предыдущие версии функций (и любой старый бинарник будет работать с новой версией библиотеки). Т.е. каждая новая версия библиотеки содержит все предыдущие функции со старыми версиями + новую функциональность с новыми версиями. Если что-то уже не используется — оно удаляется. Однако, это сложнее реализовать, поэтому коммерсантами редко используется (дороже).
Re: Версионнинг очень больших баз кода
От: vsb Казахстан  
Дата: 18.04.22 18:56
Оценка:
А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
Re[2]: Версионнинг очень больших баз кода
От: SkyDance Земля  
Дата: 18.04.22 22:59
Оценка: 7 (1) +1
vsb>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.

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

Ну и в монорепо всегда что-то где-то сломано. Нет даже самого понятия stable release.
Re: Версионнинг очень больших баз кода
От: Miroff Россия  
Дата: 19.04.22 02:40
Оценка:
Здравствуйте, Barbar1an, Вы писали:

B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули?

B>а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить

Я не встречал чтобы из идеи разделять общий код между командами хоть раз вышло что-нибудь хорошее. Единственное, хоть сколько-то разумное решение это выделить общий код в отдельный продукт с собственным циклом релизов и собственными разработчиками. А в идеале еще и открыть его в open source.
Re[2]: Версионнинг очень больших баз кода
От: Miroff Россия  
Дата: 19.04.22 02:49
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.


И в чем профит такого подхода? Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск. А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Re: Версионнинг очень больших баз кода
От: vaa  
Дата: 19.04.22 03:59
Оценка:
Здравствуйте, Barbar1an, Вы писали:

B>как вообще это делается?


B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты

B>как такое версионится?
B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули?
B>а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить

Очевидно, если компоненты самостоятельные то и должны поставляться как артефакты(модули).
т.е. к основному проекту подключили допустим dll определенной версии и с ней ведете разработку.
Если же используется общая кодовая база то тут как обычно — транк и бранч-фича в которой ведется разработка новой версии зависимости(модуля).
все это время фича синхронизируется с транком до готовности,
когда новая версия фичи готова вливаешь ее в транк. релизишь решение.
Тут главный обычно все решает и возможности системы контроля версий, языка программирования и его инструментов.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[3]: Версионнинг очень больших баз кода
От: vsb Казахстан  
Дата: 19.04.22 05:17
Оценка: +1
Здравствуйте, Miroff, Вы писали:

vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.


M>И в чем профит такого подхода?


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

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

M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.


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

M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.


Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю. Понятно, что такая модель разработки требует адаптации команд и готовности делать (и принимать) пул-реквесты в чужие проекты.

Моё имхо — монорепо это маст хэв для маленьких проектов (условно до 3 команд по 10 человек). Начиная с некоего среднего размера уже можно переходить на репозиторий для каждого компонента, т.к. всё ещё не такое большое, чтобы вызвать существенные проблемы с версиями, можно заставлять остальные проекты переходить на последние версии в разумное время и снимать их с поддержки. И начиная с некоего большого размера можно переходить назад на монорепо, уже в другом виде и с другими инструментами, т.к. когда в компании 1000 команд, с ними всеми уже общий язык находить будет маловероятно, в итоге либо всё превратится в болото, где нельзя сделать никакое изменение, либо людям даётся возможность сделать это своё изменение и пофиксить самостоятельно всех остальных.
Отредактировано 19.04.2022 5:23 vsb . Предыдущая версия . Еще …
Отредактировано 19.04.2022 5:20 vsb . Предыдущая версия .
Отредактировано 19.04.2022 5:19 vsb . Предыдущая версия .
Отредактировано 19.04.2022 5:18 vsb . Предыдущая версия .
Re[3]: Версионнинг очень больших баз кода
От: Anton Batenev Россия https://github.com/abbat
Дата: 19.04.22 09:16
Оценка:
Здравствуйте, Miroff, Вы писали:

M> Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.


Его чекаутят или селективно (нужное подмножество директорий) или лениво (подгружая / кэшируя по мере необходимости).

M> А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.


Не очень понятно почему не можешь. Зависимость по исходникам (вместо зависимости по артефактам) — твой код собирается с текущей версией исходного кода другого проекта.
Re[4]: Версионнинг очень больших баз кода
От: Miroff Россия  
Дата: 19.04.22 09:26
Оценка:
Здравствуйте, vsb, Вы писали:

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


Если пользоваелям норм, то и не надо ничего менять. Сделали сервис, запустили в прод и он там крутится годами не останавливаясь. Зачем ему непременно обновлять библиотеки?

vsb>А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.


А тестировать эти фиксы кто будет? Владелец библиотеки? Так у него в чужом коде компетенции нет, он не знает что там и почему. Владелец кода? А ему это зачем, у него свои планы по разработке,
внезапные апгрейды библиотеки туда не входят. И как это сочетается с жизненным циклом проекта? У тебя пасхальный релиз завтра, а какие-то клоуны из соседней команды ломают твой код своими апдейтами. Или апдейты приезжают не в мастер, а в ветку? Кто тогда отвечает за то чтобы эта ветка была смерджена в мастер?

С версиями как раз все просто, старая версия объявляется устаревшей, назначается план поддержки на какой-то срок, все пользователи включают миграцию в планы разработки и за несколько месяцев без суеты переезжают.
Re[5]: Версионнинг очень больших баз кода
От: vsb Казахстан  
Дата: 19.04.22 09:31
Оценка:
Здравствуйте, Miroff, Вы писали:

M>Если пользоваелям норм, то и не надо ничего менять. Сделали сервис, запустили в прод и он там крутится годами не останавливаясь. Зачем ему непременно обновлять библиотеки?


Так не бывает, всегда надо что-то обновлять. Хотя бы безопасность. Но чаще всего идут доработки и развитие в любом случае.

vsb>>А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.


M>А тестировать эти фиксы кто будет? Владелец библиотеки? Так у него в чужом коде компетенции нет, он не знает что там и почему.


Тестироваться будет само. Автотесты, фич-флаги, сознательность и тд.

> Владелец кода? А ему это зачем, у него свои планы по разработке,

M> внезапные апгрейды библиотеки туда не входят. И как это сочетается с жизненным циклом проекта? У тебя пасхальный релиз завтра, а какие-то клоуны из соседней команды ломают твой код своими апдейтами. Или апдейты приезжают не в мастер, а в ветку? Кто тогда отвечает за то чтобы эта ветка была смерджена в мастер?

Нет никаких пасхальных релизов. Ушёл коммит, собрался, прогнались тесты и всё ушло в прод.

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


Или не переезжают, куда им торопиться, не горит же. Некоторые вон до сих пор на 6 жаве сидят.
Re[2]: Версионнинг очень больших баз кода
От: SkyDance Земля  
Дата: 19.04.22 16:26
Оценка: +1
R>В идеале: Однако, единственная работающая идеально схема — это когда каждая новая версия библиотеки обеспечивает вплоть до бинарной совместимости со всеми предыдущими версиями, пока они используются. Т.е. что-то типа libc/libstdc++, когда все символы версионированы и новая функциональность выпускается с символами под новыми версиями

Без шансов, можно даже не пытаться. Слишком сложно научить среднего разработчика. И в тестировании тот еще ад.
Re[3]: Версионнинг очень больших баз кода
От: SkyDance Земля  
Дата: 19.04.22 16:27
Оценка:
M>И в чем профит такого подхода? Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.

Его никогда целиком не чекаутят. Используют всякие там on-demand файловые системы и симуляторых таковых.
Re[5]: Версионнинг очень больших баз кода
От: SkyDance Земля  
Дата: 19.04.22 16:29
Оценка:
M>Если пользоваелям норм, то и не надо ничего менять. Сделали сервис, запустили в прод и он там крутится годами не останавливаясь. Зачем ему непременно обновлять библиотеки?

Чтобы добавить новые фичи. Самому сервису эти фичи может и не нужны, но инфраструктура требует изменений — начиная от security, и заканчивая всякими там legal obligations, ну, скажем, PCI compliance.
Re[4]: Версионнинг очень больших баз кода
От: Barbar1an Украина  
Дата: 19.04.22 17:08
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.



а что за расширения?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Re[5]: Версионнинг очень больших баз кода
От: vsb Казахстан  
Дата: 19.04.22 17:19
Оценка:
Здравствуйте, Barbar1an, Вы писали:

vsb>>Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.


B>а что за расширения?


Я точно не знаю, я тут больше теоретик. Но можно начать отсюда: https://github.com/microsoft/scalar
Re[4]: Версионнинг очень больших баз кода
От: Sharov Россия  
Дата: 19.04.22 20:40
Оценка:
Здравствуйте, SkyDance, Вы писали:

M>>И в чем профит такого подхода? Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.

SD>Его никогда целиком не чекаутят. Используют всякие там on-demand файловые системы и симуляторых таковых.

Например?
Кодом людям нужно помогать!
Re[5]: Версионнинг очень больших баз кода
От: SkyDance Земля  
Дата: 20.04.22 00:35
Оценка: 8 (1)
S>Например?

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