Стратегія використання управління версіями в модульній системі

Припустимо (для простоти), що у нас є додаток із клієнтом та сервером; чи є краща ідея використовувати одне сховище для обох або пару окремих сховищ?

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

Якщо ви використовуєте git або mercurial , то, можливо, ви захочете переглянути підмодулі чи підпозиції .

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

Взявши зобов'язання над супер-сховищем, коли і клієнт, і сервер були відповідними один одному, супер-сховище дасть вам лише можливість перевірити робочу систему - так що ви ніколи не намагатиметеся запустити нового клієнта на старий сервер або навпаки.

Підмодулі / підпозиції надають всі переваги використання окремих сховищ, а також переваги одного монолітного сховища за рахунок трохи додаткової складності.

_{Ця відповідь не призначена для відстоювання gitабо hgнад іншими СКМ, просто буває так, що я знаю лише ці СКМ досить добре, щоб знати, що ця опція існує. Я, наприклад, не розумію, як svnпрацюють зовнішні організації.}

Окремо!

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

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

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

Переваги розділених сховищ полягають у можливості окремо виконати версію окремих частин системи. Хочете взяти копію Сервера минулого тижня і запустити її разом із Клієнтом цього тижня, щоб спробувати зафіксувати корінь проблеми продуктивності? Не хвилюйтесь.

У Mercurial ця схема може бути використана ->для позначення субрепо-зв'язків:

product -> client -|-> (many components)
                   |->  shared component A

        -> server -|-> (many components)
                   |->  shared component A

Продукт має підрепозиторний клієнт, сервер. Кожен з них має свої компоненти як підрепости, можливо, принаймні одне підрепортаж, що розділяється між ними.

Тегування, ймовірно, слід робити на перших двох рівнях, не нижче цього.

Коміти виконуються на рівні компонентів, суперрепозиції ефективно відстежують названі гілки та версії продукту. Іменовані гілки / закладки, як правило, краще, ніж клонують гілки за зручністю використання (тобто навчальністю) та сумісністю з субрепозитами.

hg схиляється до припущення, що суперрепости є продуктом, а комісії виконуються на найвищому рівні, але це не спрацьовує особливо добре, коли кілька продуктів використовують одні і ті ж компоненти. :-)

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

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

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

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

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

Модульність - це приємна властивість, але розділення сховищ не є інструментом для досягнення цього. Як випливає з попереднього абзацу, ви можете мати сильно зв'язані компоненти, які розділені на декілька кодових баз (небажано), і також ви можете мати високомодульні компоненти в межах однієї бази коду (бажано).

Не один раз я виступав (успішно), щоб моя команда об'єднала існуючі сховища git, оскільки це спростило розробку та розгортання.

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

• Помістити всі вихідні файли для клієнта та сервера в один каталог?

• Створити основний каталог проектів, який містить підкаталоги для клієнта та сервера?

• Тримати ці проекти повністю окремими?

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

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