Стратегія розгалуження та версії для спільних бібліотек

Ці пости здаються спорідненими, але мій мозок починає танути, намагаючись продумати це через: P

Мій роботодавець тільки почав використовувати управління джерелами, насамперед тому, що перш ніж найняти більше розробників, "сховище" було жорстким диском самотнього розробника, який працює в основному з дому. Весь написаний ним код .NET був перевірений у масовій формі, і є багато дублюваних (читайте: вставлених) копій. Зараз наша система SCM - прославлена ​​резервна копія.

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

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

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

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

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

І як би я хотів використовувати Mercurial, ми вже витратили гроші на централізований комерційний SCM (Vault), і переключення не є можливим. Крім того, я думаю, що тут проблема йде глибше, ніж вибір інструмента контролю версій.

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

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

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

Бібліотеки слід розглядати як окремі проекти та якнайшвидше їх стабілізувати. Після їх стабілізації (особливо інтерфейсів) інтеграція змін буде простішою з іншими проектами. Нові бібліотеки повинні працювати зі старим кодом. Тег стабільних бібліотечних випусків із власним ідентифікатором випуску. Спробуйте ставитись до бібліотек так, як ви ставитеся до сторонніх бібліотек.

Код, який ділиться між проектами, слід розглядати як проекти на собі. До них слід ставитися з такою ж ретельністю, як і до сторонніх бібліотек. Іншого шляху немає.

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

У будь-якому випадку ви повинні відповідати, коли оновлювати свою робочу директорію з модифікаціями, які інші проекти внесли до спільного коду. Це має статися лише тоді, коли ви готові розібратися з невідповідностями, які можуть виникнути; в іншому випадку ваша робота може стати нестабільною поза виконання.

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

Деякі переваги:

1. Простіша налагодження кожного модуля.
2. Швидше цикли збірки (відсутність перебудови бібліотек, які не змінилися)
3. Як тільки щось працює, ви менше шансів зламати його, змінивши іншу область поза цим модулем (не на 100%, але ви зменшите шанси).
4. Простіше розбити робочі завдання, якщо це не велика взаємозалежність.
5. Швидше розповсюдження дрібних фрагментів, коли ви виправляєте одну бібліотеку (велика причина, чому у вас є .dll / .so файли).

У мене є одне питання щодо цієї частини:

«Ідеальним рішенням, на який я нав'язую, є створення бібліотек окремо, кожен залежний проект будується на основі навмисно вибраних сумісних їх версій».

Ви статично пов’язуєте весь проект? Якщо так, це призведе до: 6. Зменшення зайвого розмаху коду.

Деякі мінуси:

1. Якщо проект невеликий, ви просто додаєте складності там, де він не потрібен.
2. Розгалуження безлічі модулів може перетворитись на проблему обслуговування справді великих проектів. Я не знаю "Сейфу", тому я не впевнений, чи добре, чи погано їх розгалуження.

Зараз, схоже, у вас одна кодова база вбудована відразу в одну ціль. Напевно у вас не більше п'яти розробників. Я не дуже бачу корисності розділення бібліотек занадто багато. Ви можете змінити робочий процес з коду -> компілювати -> запустити до коду -> компілювати -> скопіювати DLL -> компілювати -> запустити ... ick.

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

Без цієї інфраструктури я б відокремив проект, якщо застосовується одне з наступного:

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

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

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

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

У Mercurial є функція, яка називається підрепозиторіями. Нещодавно я прочитав цей блог від Kiln, пояснюючи, як вони працюють.

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

Можливо, Vault має подібну особливість.

До кожного модуля в SC ми додали файл метаданих, який вказує назву всіх інших модулів, від яких залежить. Продукт матиме другий файл метаданих, який вказує, яка версія кожного залежного модуля необхідна для продукту. Крім цього, це інструмент для аналізу файлів метаданих, перевірки всіх необхідних модулів та створення проекту для нашої IDE.

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