Чи є гарною практикою зберігання номерів версій програмного забезпечення у VCS?

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

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

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

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

В обох випадках можуть бути певні аспекти номера версії, які не відомі до складання CI. Наприклад, збірка CI може програмно розміщуватись у 4-му компоненті, який є справді автоматизованим номером збірки (наприклад, 140-й збір на гілці). Це також може бути номер ревізії в VCS.

Який найкращий спосіб не відставати від номера версії програмного забезпечення? Чи слід завжди підтримувати "відомі" деталі у VCS? І якщо так, то чи конфлікти між основними галузями є проблемою?

Зараз ми підтримуємо номер нашої версії за допомогою параметрів, визначених та підтримуваних у плані збірки CI (Atlassian Bamboo). Ми повинні бути обережними перед тим, як об’єднатись у нашу masterгілку, що номери версій правильно налаштовані перед початком складання CI . Що стосується робочого процесу Gitflow, я вважаю, що якби номер версії відслідковувався у контролі джерела, ми могли б гарантувати, що він налаштований належним чином, коли ми створюємо нашу releaseгілку під час підготовки до випуску. QA здійснить остаточне тестування на інтеграцію / дим / регресію на цій гілці та після входу відбувається злиття, masterяке сигналізує про зобов'язання звільнитись.

— void.pointer
джерело

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

— 5gon12eder

@ 5gon12eder Труднощі або почуття щодо самого злиття не мають значення. Це просто негативний аспект загального рішення.

— void.pointer

Відповіді:

Особисто я обираю варіант 3: зберігати інформацію про версії в метаданих VCS , зокрема, в тегах.

З допомогою Git це зробити дуже просто, оскільки є команда git describe, яка може однозначно описати фіксацію на основі тегу. Ось як це працює:

Якщо позначена поточна комісія, виведіть назву тегу.
В іншому випадку, ходити задом історії , поки ви не знайдете тег і потім виводиться опис в наступному форматі: <tag>-<number of commits since the tag>-g<abbreviated commit hash>.
Якщо в робочому дереві є неспроможні зміни, додайте -dirty.

Отже, якщо ви робите збірку релізів і позначаєте тег коміту 1.2.3, він виведе 1.2.3. Якщо ви зараз працюєте над 1.2.4, і ви зробили 4 коміти з 1.2.3 та не змінили зміни в дереві, воно виведе 1.2.3-4-gdeadbee-dirty.

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

— Йорг W Міттаг
джерело

Мені дуже подобається ця ідея, але з JIRA + Bamboo це здається важким для управління. Бамбук функціонує лише на гілках, а не на тегах, тому вам доведеться переконатися, що тег висунуто перед створенням збірки. Це схильність до помилок.

— void.pointer

git describeтакож працює з гілками: " --all - замість того, щоб використовувати лише помічені теги, використовуйте будь-який посилання, знайдений у refs/просторі імен. Ця опція дозволяє узгодити будь-яку відому гілку, гілку дистанційного відстеження або легкий тег." Не впевнений, як це працює з Bamboo. (Це, звичайно, вимагатиме ретельного іменування гілок, як і звичайний режим з тегами.)

— Jörg W Mittag

Я знаю деяких людей, які роблять повністю автоматичні релізи від Git. Рядок версій побудований git describe, ChangeLog генерується з git shortlog(ну, власне, зі скрипту, який аналізує вихід git log --pretty=tformat:<some custom format string>), а примітки до випуску створюються з опису тегу та git notesдодаються до важливих етапів віху.

— Йорг W Міттаг

Суть в тому, що тег повинен був би бути створений заздалегідь випуску , так що коммітов після нього правильно версіоніруются з базовим номером. Це суперечить принципу тегування під час або під час виходу. Bamboo збирає збірки автоматично на основі комісій master(від develop, пам’ятайте, я використовую gitflow). Що робити, якщо хтось натискає на злиття masterбез тегів? Він не використовуватиме належну версію (фактично використовував би версію останнього випуску)

— void.pointer

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

— Йорг W Міттаг

Так. Добра практика зберігати більшість номерів версії в vcs. Якщо ми розглянемо семантичну версію semver.org, де у нас є major.minor.patch.build, перші три повинні жити в vcs. Останній може бути збільшенням номера з вашого сервера збирання, який використовується для відстеження конкретного комітету, з якого робиться двійковий файл.

Щоб полегшити це у .NET, ми створили невеликий cmd-рядок exe, який має намір git. За допомогою події перед збіркою він вибирає номер збірки, який командування міста позначає під час збирання. Цей інструмент cmd-рядка автоматично генерує клас з однією константою, що містить число збірки. Решта номера версії: major.minor.patch - просто нормальна константа в іншому файлі. Ці два спільних файли входять у кожну збірку у рішенні як посилання (alt + shift-drag).

Такий підхід є досить потужним, щоб ми могли створити команду та перевірити свій код. Надіньте лазур і побудуйте його знову створити, але з номером збірки teamcity як версією DLL.

— Есбен Сков Педерсен
джерело