Який найкращий спосіб вирішити версію продукту та розгалуження довгострокових проектів?

Загалом, для довгострокових проектів, які можуть мати кілька випусків протягом життєвого циклу продуктів і потребують підтримки попередніх продуктів, який найкращий спосіб обробляти версії продукту та розгалуження бази коду?

У більш конкретному сенсі припустимо, що діє правильний розподілений варіант управління (тобто git) і що команди мають невеликі та великі розміри і що розробник може працювати над кількома проектами одночасно. Основна проблема, з якою стикається, полягає в тому, що існує договірне зобов'язання підтримувати старі версії, як вони існували в той час, а це означає, що нова розробка не може виправити старий код (продукти Microsoft Office можуть бути прикладом цього, ви отримуєте лише патчі для рік функції у вас є).

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

Скільки (і яку саме) структуру вам потрібно, багато що залежить від того, що ви хочете зробити. З’ясуйте, без чого ви не можете жити, що ви хочете мати, а що вам не байдуже.

Хороший приклад набору рішень може бути:

Речі, без яких ми не можемо жити:

• мати можливість реконструювати будь-який минулий випуск у будь-який час
• мати можливість підтримувати кілька підтримуваних основних версій продукту в будь-який час

Ми хотіли б мати речі:

• вміти виконувати поточну розробку основних функцій (для наступного великого випуску), не турбуючись про злиття гілок
• мати можливість виконувати оновлення технічного обслуговування попередніх версій

Що ми можемо жити без:

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

Якщо вище були ваші цілі, ви можете прийняти такий процес:

1. Робіть усі розробки на стволі вашого VCS ("майстер" в git)
2. Коли ви близько до основного випуску, зупиніть розробку основних функцій і зосередьтеся на стабільності системи на тиждень або близько того
3. Коли ствол здається стабільним, створіть гілку для цього основного випуску
4. Зараз основна розробка особливостей може триватись на магістралі, тоді як на гілці дозволяються лише виправлення помилок та підготовка до випуску
5. Однак усі виправлення помилок, які слід здійснити на гілці, слід спочатку перевірити на стовбурі; це гарантує, що вони також будуть присутні у всіх майбутніх випусках
6. Створіть на гілці тег (VCS), коли ви готові до випуску; цей тег можна використовувати для відтворення випуску в будь-який час, навіть після подальшої роботи над тією ж гілкою
7. Подальші випуски технічного обслуговування до цього основного випуску (незначні випуски) тепер можна готувати у відділенні; кожен буде позначений тегом перед випуском
8. У той же час основна розробка особливостей, спрямованих на наступний великий реліз, може продовжуватися на магістралі
9. Коли ви наблизитесь до цього випуску, повторіть описані вище кроки, створивши нову гілку випусків для цього випуску . Це дозволяє мати декілька основних випусків, кожен у своєму відділенні, у підтримуваному стані одночасно, з можливістю випускати окремі незначні випуски проти кожного.

Цей процес не дасть відповіді на всі ваші запитання - зокрема, вам знадобиться процес, щоб вирішити, які виправлення можна зробити в гілці випуску та забезпечити, щоб помилки спочатку не були виправлені на гілці випуску (такі виправлення завжди слід перевіряти на багажнику, де це можливо). Але це дасть вам основу для прийняття таких рішень.

"Довгостроковий" - це показник того, що вам потрібна версія, але вона не передбачає конкретної стратегії версій та розгалуження. Більш цікаве питання - скільки товарних ліній або основних версій ви хочете підтримати (що залежить від договору з вашими клієнтами). Вам буде потрібно щонайменше одне відділення для кожної лінійки продуктів / основної версії версії, на яку у вас є договір технічного обслуговування.

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

Git - це інструмент контролю версій - він управляє версіями файлів. Що ви хочете, це інструмент управління конфігурацією. Це приємно з цих доступних, але, в основному, високих $$$ від подібних IBM.

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

Я не знаю, але впевнений, що він буде існувати, додаток до інструмента CM для Git.

Це питання, схоже, дуже схоже на інше питання, на яке я нещодавно відповів .

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

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

Це непросте завдання, але попрацьоване на етапах, якщо ви добре керуєте роботою, і якщо зможете запланувати роботу так, що вам не потрібно буде "оновлювати" все все відразу.