В git, как сделать управление версиями для дюжины библиотек, все работали параллельно

Мы работаем над проектами, но мы используем много кода между проектами и имеем много библиотек, которые содержат наш общий код. По мере того, как мы реализуем новые проекты, мы находим больше способов выделить общий код и поместить его в библиотеки. Библиотеки зависят друг от друга, а проекты зависят от библиотек. Каждый проект и все библиотеки, используемые в этом проекте, должны использовать одну и ту же версию всех библиотек, на которые они ссылаются. Если мы выпустим часть программного обеспечения, нам придется исправлять ошибки и, возможно, добавлять новые функции в течение многих лет, а иногда и десятилетий. У нас около дюжины библиотек, изменения часто затрагивают более двух, и несколько команд работают над несколькими проектами параллельно, внося параллельные изменения во все эти библиотеки.

Недавно мы перешли на git и создали репозитории для каждой библиотеки и каждого проекта. Мы используем stash в качестве общего репозитория, делаем новые вещи в функциональных ветках, затем делаем запросы на извлечение и объединяем их только после просмотра.

Многие из проблем, с которыми нам приходится сталкиваться в проектах, требуют от нас внесения изменений в несколько библиотек и специфический код проекта. Они часто включают изменения интерфейсов библиотеки, некоторые из которых несовместимы. (Если вам кажется, что это звучит странно: мы взаимодействуем с оборудованием и скрываем определенное оборудование за общими интерфейсами. Почти каждый раз, когда мы интегрируем оборудование другого производителя, мы сталкиваемся со случаями, которые наши текущие интерфейсы не ожидали, и поэтому должны их усовершенствовать.) Например, представьте проект с P1использованием библиотек L1, L2и L3. L1также использует L2и L3, и L2использует L3также. Граф зависимостей выглядит так:

   <-------L1<--+
P1 <----+  ^    |
   <-+  |  |    |
     |  +--L2   |
     |     ^    |
     |     |    |
     +-----L3---+

Теперь представьте, что функция для этого проекта требует изменений P1и L3изменения интерфейса L3. Теперь добавьте проекты P2и P3в смесь, которая также ссылается на эти библиотеки. Мы не можем позволить себе переключить их на новый интерфейс, выполнить все тесты и развернуть новое программное обеспечение. Так какая альтернатива?

1. реализовать новый интерфейс в L3
2. сделать запрос на получение L3и дождаться обзора
3. объединить изменения
4. создать новый выпуск L3
5. начните работать над этой функцией P1, сделав ссылку на L3ее новую версию, затем внедрите эту функцию в P1ветку функций
6. сделайте запрос на удаление, проверьте это и объедините

(Я только что заметил, что забыл переключиться L1и L2на новый релиз. И я даже не знаю, куда это вставить, потому что это должно было бы быть сделано параллельно с P1...)

Это утомительный, подверженный ошибкам и очень длительный процесс для реализации этой функции, он требует независимых проверок (что делает проверку намного сложнее), вообще не масштабируется и, вероятно, выведет нас из бизнеса, потому что мы настолько увязнуть в процессе, что мы ничего не сделаем.

Но как мы используем ветвление и тегирование для создания процесса, который позволяет нам реализовывать новые функции в новых проектах без лишних затрат?

Вроде бы выкладываю здесь очевидное, но, возможно, стоит упомянуть об этом.

Как правило, репозитории git разрабатываются для каждой библиотеки / проекта, потому что они, как правило, независимы. Вы обновляете свой проект, а остальное вас не волнует. Другие проекты, зависящие от этого, просто обновят свою библиотеку, когда сочтут нужным.

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

Есть сильные преимущества / недостатки этого.

Преимущества:

• Отслеживаемость: ветка показывает все изменения в каждом проекте / библиотеке, связанные с этой функцией / ошибкой.
• Комплектация: просто выберите тег, и вы получите правильные источники.

Недостатки:

• Слияние: ... иногда это уже тяжело с одним проектом. С разными командами, работающими над общими ветвями, будьте готовы к ударам.
• Опасный фактор «упс»: если один сотрудник испортит хранилище, допустив какую-то ошибку, это может повлиять на все проекты и команды.

Вам решать, стоит ли цена выгоды.

РЕДАКТИРОВАТЬ:

Это будет работать так:

• Функция X должна быть реализована
• Создать ветку feature_x
• Все разработчики работают над этой веткой и работают параллельно над ней, вероятно, в специализированных каталогах, связанных с их проектом / lib
• Когда все закончится, просмотрите его, протестируйте, упакуйте, что угодно
• Слейте его обратно в мастер ... и это может быть трудной частью с тех пор, feature_yи feature_zможет быть добавлено тоже. Это становится объединением "кросс-команды". Вот почему это серьезный недостаток.

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

Решение, которое вы ищете, представляет собой инструмент управления зависимостями в координации с подмодулями git.

Инструменты, такие как:

• специалист
• Муравей
• Композитор

Вы можете использовать эти инструменты для определения зависимостей проекта.

Вы можете требовать, чтобы субмодуль был по крайней мере версии > 2.xx или обозначал диапазон версий, которые совместимы = 2.2. * Или меньше, чем конкретная версия <2.2.3

Всякий раз, когда вы выпускаете новую версию одного из пакетов, вы можете пометить его номером версии, таким образом вы можете вставить эту конкретную версию кода во все другие проекты.

подмодули

Вы должны попробовать git submodules , как предлагается в одном комментарии.

Когда проект P1относится к трем подмодулям L1, L2и L3, на самом деле сохраняет ссылку на конкретные фиксаций во всех трех хранилищах: это те рабочие версии каждой библиотеки для этого проекта .

Таким образом, несколько проектов могут работать с несколькими подмодулями: P1может ссылаться на старую версию библиотеки, в L1то время как проект P2использовал новую версию.

Что происходит при доставке новой версии L3?

• внедрить новый интерфейс в L3
• зафиксировать, протестировать , сделать запрос на извлечение, просмотреть, объединить, ... (вы не можете избежать этого)
• обеспечить L2работу L3, совершить, ...
• обеспечить L1работу с новыми L2, ...
• обеспечить P1работу с новыми версиями всех библиотек:
  • внутри P1«s локальной рабочей копии L1, L2и L3, fetche изменения вы заинтересованы.
  • зафиксировать изменения, git add L1 L2 L3зафиксировать новую ссылку на модули
  • вытащить запрос P1, проверить, просмотреть, вытащить запрос, объединить ...

методология

Это утомительный, подверженный ошибкам и очень длительный процесс для реализации этой функции, он требует независимых проверок (что делает проверку намного сложнее), вообще не масштабируется и, вероятно, выведет нас из бизнеса, потому что мы настолько увязнуть в процессе, что мы ничего не сделаем.

Да, это требует независимых проверок, потому что вы меняете:

• библиотека
• библиотеки, которые зависят от этого
• проекты, которые зависят от нескольких библиотек

Вы были бы разорены, потому что доставляете дерьмо? (Может и нет). Если да, то вам нужно выполнить тесты и просмотреть изменения.

С помощью соответствующих инструментов git (даже gitk) вы можете легко увидеть, какие версии библиотек использует каждый проект, и вы можете независимо обновлять их в соответствии с вашими потребностями. Подмодули идеально подходят для вашей ситуации и не замедляют процесс.

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

(Изменить) еще одна вещь, которая может помочь вам, это сгруппировать обзоры кода. Вы фиксируете все изменения и ждете, пока вы не распространите эти изменения во всех библиотеках и проектах, которые их используют, прежде чем отправлять запросы на извлечение (или прежде чем позаботиться о них). Вы заканчиваете тем, что делаете больший обзор для всей цепочки зависимостей. Может быть, это поможет вам сэкономить время, если каждое локальное изменение невелико.

Итак, я понимаю, что для P1 вы хотите изменить интерфейс L3, но вы хотите, чтобы другие P2 и P3, которые зависят от интерфейса L3, изменились сразу. Это типичный случай обратной совместимости. Есть хорошая статья об этой сохраняющей обратной совместимости

Есть несколько способов решить эту проблему:

• Вы должны каждый раз создавать новые интерфейсы, которые могут расширять старые интерфейсы.

ИЛИ ЖЕ

• Если вы хотите удалить старый интерфейс через некоторое время, у вас может быть несколько версий интерфейсов, и как только все зависимые проекты будут перемещены, вы удалите старые интерфейсы.

Если я правильно понимаю вашу проблему:

• у вас есть 4 взаимосвязанных модуля, P1 и L1 до L3
• вам нужно внести изменения в P1, что в конечном итоге повлияет на L1 на L3
• это считается ошибкой процесса, если вам нужно изменить все 4 вместе
• это считается ошибкой процесса, если вам нужно изменить их все 1 на 1.
• это считается ошибкой процесса, если вам необходимо заранее определить фрагменты, в которые необходимо внести изменения.

Таким образом, цель в том, чтобы вы могли сделать P1 и L1 за один раз, а затем через месяц сделать L2 и L3 за один раз.

В мире Java это тривиальный и, возможно, стандартный способ работы:

• все идет в одном хранилище без соответствующего использования ветвления
• модули компилируются + соединяются вместе maven на основе номеров версий, а не факта, что все они находятся в одном дереве каталогов.

Таким образом, вы можете иметь код на локальном диске для L3, который не будет компилироваться, если он компилируется с копией P1 в другом каталоге на вашем диске; к счастью, это не так. Java может сделать это напрямую, потому что рассказы о компиляции / компоновке помещаются в скомпилированные файлы jar, а не в исходный код.

Я не знаю ранее существовавшего широко используемого решения этой проблемы для мира C / C ++, и я думаю, что вы вряд ли захотите переключать языки. Но что-то может быть легко взломано вместе с make-файлами, которые сделали эквивалентную вещь:

• установленные библиотеки + заголовки известных каталогов со встроенными номерами версий
• изменил пути компилятора для каждого модуля в каталог для соответствующих номеров версий

Вы даже можете использовать поддержку C / C ++ в maven , хотя большинство разработчиков C будут смотреть на вас странно, если вы это сделаете ...

Существует простое решение: разрезать ветки релизов по всему репозиторию, объединять все исправления со всеми активно поставляемыми релизами (это легко сделать в ясном случае в git).

Все альтернативы создадут ужасный беспорядок со временем и с ростом проекта.