Що є найкращим способом версії багатокомпонентного проекту


10

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

Хтось знайшов простий спосіб зробити це, крім списку кожного окремо?


1
Чи всі компоненти побудовані одночасно? Вони "звільнені" одночасно?
Адам Лір

1
@Anna Lear: ні, компоненти будуються та випускаються в різний час.
Джон Сміт

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

Яка ваша мета при розробці версій? Для чого використовується ця інформація про версію ? Звіти про помилки? перевірка відповідності оновлення? ліцензування? Відповідаючи на ці запитання, ви можете відповісти на ваше основне запитання.
Алекс Фейнман

Відповіді:


7

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


2
Як це виглядатиме у вашій системі контролю версій? Ви "закріплюєте" всі підпроекти, коли робите основний реліз?
Роберт Харві

Коли ми готуємо основний випуск, всі компоненти переглядаються, і якщо вони мають зміни, то вони отримують оновлену версію на той час. Версія позначена в Kiln.
Дейв Най

3

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


1
Це я щось думав, але як ти керуєш цим у середовищі CI / CD? Зберігання цієї документації здається справжньою PITA
Sineesthetic

1

Версії - це проблема, яка є окремою від розробки додатків на основі компонентів. Або ви хочете версію кожного компонента, або ви хочете версію всієї програми.

Хороший відомий зразок версій - від Microsoft :

major version.minor version.build number.revision

Наприклад, ви можете бачити файли DLL на платформі .NET з такими версіями, як 2.0.3600.1, або щось подібне.

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


Я не згоден з вашою стратегією створення номерів. Номер збірки , як правило , змінюється кожен раз , коли ви побудувати проект для даного компонента, так що не буде працювати.
Роберт Харві

@Robert, так, скоро збірки стає великою кількістю. Ось чому деякі інші системи не включають його. Ти вільний їхати. Але основна та другорядна версія виходять практично з будь-якої системи версій.
Саїд Неаматі

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

1

Будьте обережні з версією, це може вбити вас :-) Не намагайтеся ускладнювати речі.

Я думаю, що наступний підхід може вам допомогти:

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

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

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


1

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

Якщо ви дотримуєтеся подібного до шаблону Microsoft:

major-version.minor-version.build-number.revision

Ви можете використовувати .revision для відстеження версії кожного окремого компонента, а також використовувати незначні та основні номери версій для відстеження повної зміни продукту звичайним чином.

Якщо ви дотримуєтеся подібного до цього шаблону:

Major-Version.Minor-Version.Build-Number

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


0

Цілі книги написані про версії програмного забезпечення.

Ось підхід, який я використовую.

Кожна частина має версію у вигляді:

major.minor.developmental

Кожне з них - це число, починаючи з 0.

Для формального випуску (тобто для клієнтів) частина розробника завжди повинна бути 0 як предмет політики.

Майор збільшується за рішенням маркетингу.

Незначні збільшуються за рахунок випуску набір функцій - на ринок.

Приклад:

  • Я починаю розробку нового компонента, тому номер моєї версії буде 0.0.1. Коли я відпускаю свій стіл колегам, наприклад, для внутрішнього тестування, кількість розробників піднімається до 0,0,2, 0,0,3 тощо.

  • Я випускаю цю нову річ на ринок як 1.0.0, де єдиною дозволеною зміною від кінця розробки до випуску було змінити номер версії (наприклад, 0.0.43 -> 1.0.0).

  • Деякі нові функції потрібно додати. Я починаю роботу над базовою лінією 1.0.0, додаючи ці функції, тому версії, які я випускаю колегам для тестування, є 1.0.1, 1.0.2 тощо.

  • Наступні функції випускаються на ринок як 1.1.0.

  • Маркетинг вирішує, що наступна велика річ буде справді великою, тому вона вийде як 2.0.0. Я починаю роботу над 1.1.1, просуваючись через 1.1.x, і випускаю як 2.0.0.

І так цикл повторюється.

Такий підхід для кожного компонента дає можливість простеження походження.

Для управління розробкою використовуйте гілки та теги (мітки, незалежно від термінології вашого дня), використовуючи гілки та джерела (та об'єкт).

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

Цілком імовірно, що ваш процес випуску вимагатиме ретельної думки. Використання цього підходу включає деякі ручні кроки, і це може бути небажаним - все залежить від того, як ваша система побудови вводить номери версій у кінцевий об'єкт. Для сильно вбудованого коду, де номери версій - це лише названі номери (наприклад, #defined у коді С), у вас є невеликий вибір, але робити все це в будь-якому випадку вручну. Настільні платформи з приємними графічними інтерфейсами часто роблять це набагато дружнішим.


Так ви в основному говорите, що для версії окремих компонентів ви збільшуєте третє число, а для версії всієї системи збільшуєте перший або другий номер для кожного компонента?
Роберт Харві

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

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

0

Підсумок

Для мене єдиним надійним способом версії програмного забезпечення є використання ідентифікатора хешу чи набору змін із вашої системи контролю версій.

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

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

Приклад з особистого досвіду

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

Цей рядок редагування відображався, коли ви переходили на сторінку about і записувався у файл журналу кожного разу при запуску програми. Вона була такої форми:

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

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

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

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.