Семантична версія у Agile

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

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

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

Для типового управління випусками потрібно, щоб ваша збірка створювала номер збірки, щоб перетворювати DLL-версії кожен раз при їх розгортанні. Це дозволить пізніше перевірити, яка версія розгорнута на даному сервері.

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

Якщо класична схема семантичного версії "MAJOR.MINOR.PATCH" має сенс, залежить від того, до кого ви розгортаєтесь, і особливо, коли і як часто ви розгортаєтесь до кінцевого користувача . Схема найбільш корисна, якщо ви працюєте зі стабільним випуском "4.5", де ви починаєте з 4.5.0. Версії 4.5.1, 4.5.2 тощо містять лише виправлення помилок, тоді як ви вже працюєте над версією 4.6.

Наприклад, якщо ви надаєте "стабільну гілку" для свого кінцевого користувача, надайте їй версію 4.5.0 для початкового розгортання та 4.5.1, 4.5.2 кожного разу, коли випускаєте виправлення. У вашій внутрішній "спритній" розробці та розгортанні середнього спринту ви вже можете мати версію 4.6, просто називати її "бета-версією". Кожного разу, коли ви розгортаєте його у середині спринту, додайте автоматично створений номер збірки на зразок "4.6.beta build 123". Коли ваш спринт закінчиться, призначте його "4.6.0" і перемкніть номер версії для наступного спринту внутрішньо на "4.7". Починаючи з ".0" - це лише умова, ви також можете використовувати ".0" для тегування бета-версій і починати з ".1" для своїх кінцевих користувачів. ІМХО слово "бета" набагато виразніше, говорить усім спринт "ще не завершено".

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

Ви знайдете стратегію випуску двох відокремлених гілок, однієї "стабільної" гілки з семантичними номерами версій та "гілки розвитку", позначеної номерами збірки або чогось подібного, у безлічі продуктів з відкритим кодом, таких як Inkscape, Firefox або 7-zip.

Якщо, однак, ви не працюєте з окремими гілками стабільності та розробки та випускаєте нову версію для кінцевого користувача щодня, ви також повинні збільшувати номер версії щодня. У такому випадку номери версій "4.5.1", "4.5.2", ..., ймовірно, відображають ваші окремі розгортання, і не вказують на різницю між виправленнями помилок та іншими змінами. Це може бути нормально, це просто не класичне "семантичне перетворення". У цьому сценарії ви також можете розгорнути версії 4.5, 4.6, 4.7, 4.8, що не дає реальної різниці.

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

Я буду використовувати номери побудови. Зазвичай номер збірки відповідав би найвищій версії системи управління версіями. Якщо число збірних понеділок склало 1745, а протягом вівторка було перевірено 5 змін, кількість збірних ввечері вівторка складе 1750.

Потім складіть короткий підсумок того, що змінилося між 1745 і 1750 роками.

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

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

У журналі змін ви можете перелічити проміжні версії з відповідними їх описами або просто згрупувати всі зміни у "випущену" версію та пропустити версії між ними.

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