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

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

Моя проблема - как отследить семантическое управление версиями продуктов, разработанных и поддерживаемых таким образом? Если выпуск будет происходить каждые 14 дней, это будет легко, я увеличу номер версии и отмечу все изменения в журнале изменений. Но что, если изменения будут внедряться постоянно? Должна ли быть увеличена версия при каждом развертывании? Или я должен дождаться окончания спринта и после этого сделать некоторое «возобновление» и увеличить номер версии только один раз за итерацию независимо от фактического развертывания? Каковы лучшие практики для семантического версионирования в Agile?

РЕДАКТИРОВАТЬ: Чтобы лучше объяснить мои потребности, я хочу в первую очередь список изменений для заинтересованных сторон. Я не думаю, что они будут заинтересованы в новой записи в журнале изменений после каждого внесенного изменения.

Для типичного управления выпусками вам потребуется, чтобы система сборки генерировала номер сборки, чтобы библиотеки 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, что не дает реальной разницы.

Относительно вашего вопроса о записях в вашем журнале изменений: ИМХО, когда что-то видимо конечному пользователю, стоит внести запись в журнал изменений, как только вы развернете изменение. Например, если вы используете переключатели функций и вносите изменения в некоторые недоделанные функции, которые еще не активированы для пользователя, это не входит в список изменений. Если вы выполняете только рефакторинг без видимых изменений для пользователя, это не входит в список изменений. Если вы исправите ошибку, которая могла повлиять на некоторых пользователей, это определенно входит в список изменений - и об этом следует упомянуть в то же время, когда вы устанавливаете исправление. И не имеет значения, выпускаете ли вы ежедневно, ежемесячно или ежегодно.

Я бы использовал номера сборки. Обычно номер сборки соответствует самой высокой версии системы контроля версий. Если в понедельник номер сборки был 1745, а во вторник было проверено 5 изменений, то номер сборки во вторник будет 1750.

Затем составьте краткое резюме того, что изменилось между 1745 и 1750 годами.

Затем каждый раз, когда вы обновляете номер версии вашей системы, вы можете складывать все краткие сводки из сборок, чтобы получить изменения с последнего номера версии на новую.

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

В журнале изменений вы можете либо перечислить промежуточные версии с соответствующими описаниями, либо просто сгруппировать все изменения в «выпущенную» версию и пропустить промежуточные версии.

Изначально я боялся, что пользователи найдут «дыры» между номерами версий проблемными, но как только они узнают об этом, на практике это не проблема. Большим преимуществом является то, что увеличение числа после каждой истории делает процесс менее подверженным ошибкам - вам не нужно проверять всю работу за 2 недели, чтобы решить, каким будет следующий номер версии - при просмотре одной истории это очевидно , Кроме того, «скачки» в номерах версий между каждым выпуском дают приблизительную оценку количества изменений, внесенных в выпуск. В общем, я обнаружил, что эта система работает хорошо (это было с внутренними клиентами компании, но если вы уже работаете в гибком цикле выпуска, она должна работать и для внешних клиентов).