ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты
как такое версионится?
ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули?
а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>как вообще это делается?
B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты B>как такое версионится?
Честно говоря, я не очень верю что один и тот же код может развиваться двумя разными командами.
То есть на практике я такого не видел, но возможно есть варианты, да и я вообще мало чего видел.
Но на мой взгляд, обычно код контролируется одной командой, "общий код" = "бесхозный код" — не должно такого быть imho.
На базе гита внесение нужной правки в "чужой" код можно организовать pull request например из другой команды,
такой механизм любая более-менее современная система управления кодом предоставит.
Если код оформлен в виде библиотеки, ну там nuget/npm модуля это уже другой случай, все равно что использовать 3rd-party библиотеку.
То есть, имеем тогда общий код в виде отдельного "продукта" и его собственного репозитория.
Но тут еще зависит от используемой платформы и какого рода "модули" она поддерживает.
Я в том смысле, многие поддерживают локальные (внутри компании) репозитории для модулей типа npm или там nuget.
Здравствуйте, Barbar1an, Вы писали:
B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули?
Можно выносить в отдельные либы и через пакетный менеджер вроде конана подтягивать как зависимость. Проблема тут очевидна, довольно длительный путь интеграции изменений в общую часть т.к. надо со всеми договориться и пройти все тесты, потом миграция с тестированием новой версии либы во все продукты. Если компания очень крупная, то сможет себе позволить, наверное. С CI/DI будет полегче, но оно не панацея конечно же.
B>как вообще это делается?
B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты B>как такое версионится? B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули? B>а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить
В реальности: IMHO, либо нормальный пакетный менеджер, если все пишется на одном языке. Либо система сборки, реализующая функциональность пакетного менеджера. Плюс некая политика обратной совместимости, чтобы в одном exe'шнике не было 10-ти версий одной бибилиотеки с учетом транзитивных зависимостей.
Ну, либо серебряная пуля — микросервисы. Там, конечно, тоже нужно отслеживать зависимости, но одна из 2-х задач, которые решают микросервисы — обеспечить возможность работы разных команд независимо над общим проектом.
В идеале: Однако, единственная работающая идеально схема — это когда каждая новая версия библиотеки обеспечивает вплоть до бинарной совместимости со всеми предыдущими версиями, пока они используются. Т.е. что-то типа libc/libstdc++, когда все символы версионированы и новая функциональность выпускается с символами под новыми версиями. При этом в каждой сборке присутствуют все предыдущие версии функций (и любой старый бинарник будет работать с новой версией библиотеки). Т.е. каждая новая версия библиотеки содержит все предыдущие функции со старыми версиями + новую функциональность с новыми версиями. Если что-то уже не используется — оно удаляется. Однако, это сложнее реализовать, поэтому коммерсантами редко используется (дороже).
vsb>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
Начиная с определенного размера средств для работы с такими репозиториями становится маловато. Распределенные кэширующие билд-системы, опять же, надо уметь настроить, и тратиться на их поддержку. В общем, довольно тяжелая инфра.
Ну и в монорепо всегда что-то где-то сломано. Нет даже самого понятия stable release.
Здравствуйте, Barbar1an, Вы писали:
B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули? B>а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить
Я не встречал чтобы из идеи разделять общий код между командами хоть раз вышло что-нибудь хорошее. Единственное, хоть сколько-то разумное решение это выделить общий код в отдельный продукт с собственным циклом релизов и собственными разработчиками. А в идеале еще и открыть его в open source.
Здравствуйте, vsb, Вы писали:
vsb>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
И в чем профит такого подхода? Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск. А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Здравствуйте, Barbar1an, Вы писали:
B>как вообще это делается?
B>ну предположим компания очень крупная и у нее 100500 проектов, и которые ессно обязательно испольщзуют общие компоненты B>как такое версионится? B>ну например в гите. код разбивается на продукты, у каждого продукта свой репо, а общий код референсится через сабмодули? B>а другие варианты? бывают? особено такие которые както решают то что в разных проектах может редактироваться общий код который потом может быть сложно мержить
Очевидно, если компоненты самостоятельные то и должны поставляться как артефакты(модули).
т.е. к основному проекту подключили допустим dll определенной версии и с ней ведете разработку.
Если же используется общая кодовая база то тут как обычно — транк и бранч-фича в которой ведется разработка новой версии зависимости(модуля).
все это время фича синхронизируется с транком до готовности,
когда новая версия фичи готова вливаешь ее в транк. релизишь решение.
Тут главный обычно все решает и возможности системы контроля версий, языка программирования и его инструментов.
Здравствуйте, Miroff, Вы писали:
vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
M>И в чем профит такого подхода?
В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.
А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.
M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.
Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.
M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю. Понятно, что такая модель разработки требует адаптации команд и готовности делать (и принимать) пул-реквесты в чужие проекты.
Моё имхо — монорепо это маст хэв для маленьких проектов (условно до 3 команд по 10 человек). Начиная с некоего среднего размера уже можно переходить на репозиторий для каждого компонента, т.к. всё ещё не такое большое, чтобы вызвать существенные проблемы с версиями, можно заставлять остальные проекты переходить на последние версии в разумное время и снимать их с поддержки. И начиная с некоего большого размера можно переходить назад на монорепо, уже в другом виде и с другими инструментами, т.к. когда в компании 1000 команд, с ними всеми уже общий язык находить будет маловероятно, в итоге либо всё превратится в болото, где нельзя сделать никакое изменение, либо людям даётся возможность сделать это своё изменение и пофиксить самостоятельно всех остальных.
Здравствуйте, Miroff, Вы писали:
M> Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.
Его чекаутят или селективно (нужное подмножество директорий) или лениво (подгружая / кэшируя по мере необходимости).
M> А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Не очень понятно почему не можешь. Зависимость по исходникам (вместо зависимости по артефактам) — твой код собирается с текущей версией исходного кода другого проекта.
Здравствуйте, vsb, Вы писали:
vsb>В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.
Если пользоваелям норм, то и не надо ничего менять. Сделали сервис, запустили в прод и он там крутится годами не останавливаясь. Зачем ему непременно обновлять библиотеки?
vsb>А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.
А тестировать эти фиксы кто будет? Владелец библиотеки? Так у него в чужом коде компетенции нет, он не знает что там и почему. Владелец кода? А ему это зачем, у него свои планы по разработке,
внезапные апгрейды библиотеки туда не входят. И как это сочетается с жизненным циклом проекта? У тебя пасхальный релиз завтра, а какие-то клоуны из соседней команды ломают твой код своими апдейтами. Или апдейты приезжают не в мастер, а в ветку? Кто тогда отвечает за то чтобы эта ветка была смерджена в мастер?
С версиями как раз все просто, старая версия объявляется устаревшей, назначается план поддержки на какой-то срок, все пользователи включают миграцию в планы разработки и за несколько месяцев без суеты переезжают.
Здравствуйте, Miroff, Вы писали:
M>Если пользоваелям норм, то и не надо ничего менять. Сделали сервис, запустили в прод и он там крутится годами не останавливаясь. Зачем ему непременно обновлять библиотеки?
Так не бывает, всегда надо что-то обновлять. Хотя бы безопасность. Но чаще всего идут доработки и развитие в любом случае.
vsb>>А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.
M>А тестировать эти фиксы кто будет? Владелец библиотеки? Так у него в чужом коде компетенции нет, он не знает что там и почему.
Тестироваться будет само. Автотесты, фич-флаги, сознательность и тд.
> Владелец кода? А ему это зачем, у него свои планы по разработке, M> внезапные апгрейды библиотеки туда не входят. И как это сочетается с жизненным циклом проекта? У тебя пасхальный релиз завтра, а какие-то клоуны из соседней команды ломают твой код своими апдейтами. Или апдейты приезжают не в мастер, а в ветку? Кто тогда отвечает за то чтобы эта ветка была смерджена в мастер?
Нет никаких пасхальных релизов. Ушёл коммит, собрался, прогнались тесты и всё ушло в прод.
M>С версиями как раз все просто, старая версия объявляется устаревшей, назначается план поддержки на какой-то срок, все пользователи включают миграцию в планы разработки и за несколько месяцев без суеты переезжают.
Или не переезжают, куда им торопиться, не горит же. Некоторые вон до сих пор на 6 жаве сидят.
R>В идеале: Однако, единственная работающая идеально схема — это когда каждая новая версия библиотеки обеспечивает вплоть до бинарной совместимости со всеми предыдущими версиями, пока они используются. Т.е. что-то типа libc/libstdc++, когда все символы версионированы и новая функциональность выпускается с символами под новыми версиями
Без шансов, можно даже не пытаться. Слишком сложно научить среднего разработчика. И в тестировании тот еще ад.
M>Если пользоваелям норм, то и не надо ничего менять. Сделали сервис, запустили в прод и он там крутится годами не останавливаясь. Зачем ему непременно обновлять библиотеки?
Чтобы добавить новые фичи. Самому сервису эти фичи может и не нужны, но инфраструктура требует изменений — начиная от security, и заканчивая всякими там legal obligations, ну, скажем, PCI compliance.
Здравствуйте, vsb, Вы писали:
vsb>Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.
а что за расширения?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
vsb>>Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.
B>а что за расширения?
Здравствуйте, SkyDance, Вы писали:
M>>И в чем профит такого подхода? Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск. SD>Его никогда целиком не чекаутят. Используют всякие там on-demand файловые системы и симуляторых таковых.
У каждой компании свой колхоз. Почти всегда этот колхоз работает только на жестко контролируемой виртуалке, на которой, собственно, и ведется разработка. Компьютеры, которые дают сотрудникаам, очень часто есть просто монитор для терминала этого сервера. Вся разработка — удаленно.
