Як робити версії для десятка бібліотек у git, паралельно працювали

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

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

Багато питань, з якими нам доводиться вирішувати проекти, вимагають зміни в декількох бібліотеках та конкретного коду проекту. Вони часто включають зміни інтерфейсів бібліотеки, деякі з яких несумісні. (Якщо ви думаєте, що це звучить риба. Ми взаємодіємо з обладнанням і ховаємо конкретне обладнання за загальними інтерфейсами. Майже кожен раз, коли ми інтегруємо якесь інше обладнання виробника, ми стикаємося з випадками, коли наші поточні інтерфейси не передбачали, і тому доводиться їх удосконалювати.) наприклад, уявіть проект з 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 repos розроблені відповідно до ліб / проекту, оскільки вони, як правило, незалежні. Ви оновлюєте свій проект і не піклуєтесь про інше. Інші проекти залежно від цього просто оновлюватимуть свою область, коли вони вважають за потрібне.

Однак ваш вигляд здається сильно залежним від співвідносних компонентів, так що одна особливість зазвичай впливає на багато з них. І все це має бути упаковано як пакет. Оскільки реалізація функції / зміни / помилки часто потребує адаптації відразу декількох різних бібліотек / проектів, можливо, має сенс розмістити їх усіх в одному репо.

У цьому є сильні переваги / недоліки.

Переваги:

• Простежуваність: філія показує все, що було змінено у кожному проекті / лібі, пов'язаному з цією функцією / помилкою.
• Пакет: просто виберіть тег, і ви отримаєте всі джерела.

Недоліки:

• Об'єднання: ... іноді вже важко з одним проектом. З різними командами, що працюють у спільних відділеннях, будьте готові до досягнення впливу.
• Небезпечний фактор "ой": якщо один працівник заблудить сховище, зробивши помилку, це може вплинути на всі проекти та команди.

Вам належить знати, чи варта ціна вигоди.

Редагувати:

Це діятиме так:

• Функція X повинна бути реалізована
• Створити відділення feature_x
• Усі задіяні розробники працюють над цією галуззю і паралельно працюють над нею, ймовірно, у спеціалізованих довідниках, пов’язаних з їх проектом / lib
• Після того, як він закінчиться, перегляньте його, протестуйте, упакуйте, що завгодно
• Об'єднати його назад в майстра ... і це може бути жорсткою частиною , так як в той же час feature_yі , feature_zможливо, був доданий також. Це стає злиттям "перехресної команди". Ось чому це серйозний недолік.

тільки для запису: Я думаю, що це в більшості випадків погана ідея, і це слід робити обережно, оскільки недолік злиття зазвичай вище, ніж той, який ви отримуєте за допомогою управління залежностями / належного відстеження функцій.

Ви шукаєте рішення - це інструмент управління залежністю в координації з підмодулями git

Такі інструменти, як:

• Мейвен
• Мураха
• Композитор

Ці інструменти можна використовувати для визначення залежностей проекту.

Ви можете вимагати від підмодулю мати принаймні версію > 2.xx або позначати діапазон версій, сумісних = 2.2. * Або менше, ніж певна версія <2.2.3

Щоразу, коли ви випускаєте нову версію одного з пакетів, ви можете позначити її номером версії, таким чином ви можете ввести цю конкретну версію коду у всі інші проекти

Підмодулі

Спробуйте спробувати підмодулі , як це запропоновано в одному коментарі.

Коли проект 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).

Усі альтернативи створять жахливий безлад з часом та з ростом проекту.