Хорошая стратегия для внедрения системы управления версиями
Я уже давно борюсь с версионным программным обеспечением. Я не говорю о соглашении об именах, я говорю о том, как на самом деле применить версию в системе сборки вплоть до релиза.
Я обычно использую major.minor.maintenance- [release type] т.е. 1.0.2-rc1
Проблема заключается в управлении номером версии. Я пробовал много способов (вставлять его в файл сборки, файл свойств, базу данных и т. Д. И т. Д.), Но я не нашел ничего, что действительно хорошо работает.
Самым близким, что я придумал, является использование Jira, которое я задокументировал здесь: http://blog.sysbliss.com/uncategorized/release-management-with-atlassian-bamboo-and-jira.html
Мне интересно, есть ли у кого-нибудь хорошие идеи по этому поводу. Кроме того, интересно, как люди справляются с выпуском версии.... т.е. если я выпускаю / внедряю версию 1.0.0-rc1, делаю ошибки, обнаруженные в этом выпуске, затем регистрируюсь в 1.0.0 (следующий / производственный выпуск).
6 ответов
Microsoft использует <major>.<minor>.<patch>-<build number> (или вариант).
Мне нравится использовать <major>.<minor>.<buildnumber>
Там, где я работаю, мы используем систему Maven: артефакт [-major-minor-revision][-SNAPSHOT], который позволяет нам разрабатывать "текущие" версии, которые изменяются в момент уведомления (SNAPSHOT), и те, которые были официально выпущены., Вот некоторые примеры:
электронная почта-услуга-1.0.0-SNAPSHOT.jar
Если в нем есть SNAPSHOT, значит, он не прошел полный набор тестов или является экспериментом разработчика. Если у него нет SNAPSHOT, то это кандидат на релиз. Мы поддерживаем репозиторий кандидатов на выпуск, и самые последние отправляются на развертывание, как только тестировщики будут довольны им.
Всем этим можно управлять с помощью нескольких простых записей в файле сборки под Maven. Смотрите учебник Maven2
Это, вероятно, мертвый пост сейчас, но я все равно добавлю свои два цента. Я придерживаюсь мнения, что сборочные числа должны что-то значить для всех, кто их видит. Так что я лично считаю, что это хороший способ назвать версии:
Major.minor.patch.revision - например, 1.1.4.2342
Основные / второстепенные числа довольно очевидны. Но с точки зрения 3-го числа, это все еще должно что-то значить для клиента. Я выпустил эту новую версию для вас, мистер Клиент, но она не стоила нового незначительного числа, так как мы только исправили некоторые ошибки. Итак, мы увеличили номер патча.
Четвёртое число обычно ничего не значит для клиента, поэтому вы также можете сделать его полезным для вас и любого другого лица в вашей компании, которое его видит. Так что для нас этот номер - номер редакции SVN. Он сообщает нам, какая именно редакция была ответственна за эту версию, чтобы мы могли вытащить ее в любое время, чтобы воссоздать ее. Разветвленный код, очевидно, тоже достигает этого, но не до 100% уверенности.
Кроме того, еще одним преимуществом полностью числового номера версии является то, что он легко интегрируется практически в каждую систему непрерывной сборки.
В любом случае, это мои два цента.
+1 к решению Jira/Bamboo. Единственной дополнительной информацией о сборке, которую я бы включил (для моих целей), является Subversion Release, хотя операция тегирования составляет 80% от того, что я хочу.
Вручную поддерживать информацию о выпуске / версии - королевская боль. Позволить JIRA водить машину - это отличная идея.
На последнем вопросе, где ошибки и дефекты регистрируются и releasing версия:
- Дефект / проблема регистрируется в выпуске, где она появляется. Дефект в 1.0.0-rc1 регистрируется против 1.0.0-rc1
- JIRA имеет (или, возможно, мы добавили) поле "Fix-For", которое будет иметь запланированный выпуск, в данном случае 1.0.0
- Если дефект / проблема достаточно серьезны, может потребоваться добавить еще один выпуск 'rc'.
- Релиз выпускается, когда нет остающихся критических дефектов / проблем, и клиент (или руководство) соглашается, что любые оставшиеся проблемы могут быть отложены
Прелесть управления этим с помощью JIRA заключается в том, что добавление выпусков, создание журналов изменений и т. Д. Автоматизировано довольно хорошо.
Мы также используем <major>.<minor>.<buildnumber> и мы управляем этим с помощью CruiseControl/(.NET) на нашем сервере сборки. И используйте Wix и CruiseControl Config для управления основными младшими номерами - все еще увеличивайте их вручную - но номер сборки происходит автоматически на сервере сборки. Я полагаю, что вы также можете настроить правило на приращение основного / вспомогательного автоматически - мы просто хотели бы сделать это вручную, чтобы у разработчика потребовалось осознанное мышление, когда пришло время назвать определенный уровень выпуска.
Major.Minor.BuildDateNumber.DailyBuildNumber
Major и Minor устанавливаются нами, вручную увеличивая их по своему усмотрению.
BuildDateNumber - это количество месяцев с начала проекта, умноженное на 100, плюс номер дня текущего месяца.
DailyBuildNumber увеличивается для каждой сборки после полуночи каждый день, начиная с нуля.
Например, 4-я сборка выпуска 5.2 10 июля, когда проект начался 1 января того же года, будет иметь номер версии
5.2.710.3
Все это рассчитывается для нас задачей Version в Nant.
Это сохраняет номера версий уникальными, а также позволяет нам быстро рассчитать, когда установка была построена.