Хорошая стратегия для внедрения системы управления версиями

Question

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

Я обычно использую major.minor.maintenance- [тип выпуска] то есть 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 (следующий / производственный выпуск).

Answer 1

Microsoft использует <major>.<minor>.<patch>-<build number> (или вариант).

Мне нравится использовать <major>.<minor>.<buildnumber>

Answer 2

Это, вероятно, мертвый пост сейчас, но я все равно добавлю свои два цента. Я придерживаюсь мнения, что сборочные числа должны что-то значить для всех, кто их видит. Так что я лично считаю, что это хороший способ назвать версии:

major.minor.patch.revision - например, 1.1.4.2342

Основные / второстепенные числа говорят сами за себя. Но с точки зрения 3-го числа, это все еще должно что-то значить для клиента. Я выпустил эту новую версию для вас, мистер Клиент, но она не стоила нового небольшого числа, так как мы просто исправили некоторые ошибки. Итак, мы увеличили номер патча.

4-й номер обычно ничего не значит для клиента, так что вы могли бы также сделать его полезным для вас и любого другого лица в вашей компании, которое его видит. Так что для нас этот номер - номер редакции SVN. Он точно говорит нам, какая редакция была ответственна за эту версию, так что мы можем вытащить ее в любое время, чтобы воссоздать ее. Разветвленный код, очевидно, тоже достигает этого, но не до 100% уверенности.

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

В любом случае, это мои два цента.

Answer 3

Там, где я работаю, мы используем систему Maven: артефакт [-major-minor-revision] [- SNAPSHOT], который позволяет нам разрабатывать версии «в процессе», которые изменяются в момент уведомления (SNAPSHOT), и те, которые был официально освобожден. Вот некоторые примеры:

Email-услуги-1.0.0-SNAPSHOT.jar

электронная почта-веб-2.3.11.war CRM-2.5.0.ear

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

Всем этим можно управлять с помощью нескольких простых записей в файле сборки под Maven. См. Учебник Maven2

Answer 4

+ 1 в растворе Jira / Bamboo. Единственная дополнительная информация о сборке, которую я бы включил (для моих целей), это Subversion Release, хотя операция тегирования составляет 80% от того, что я хочу.

Вручную поддерживать информацию о выпуске / версии - королевская боль. Позволить JIRA водить машину - это отличная идея.

По последнему вопросу, где регистрируются ошибки / дефекты и releasing версия:

• Дефект / проблема регистрируется в выпуске, в котором она появляется. Дефект в 1.0.0-rc1 регистрируется против 1.0.0-rc1
• JIRA имеет (или, возможно, мы добавили) поле «Fix-For», в котором будет запланированный выпуск, в данном случае 1.0.0
• Если дефект / проблема достаточно серьезны, может потребоваться добавить еще один выпуск 'rc'.
• Релиз выпускается, когда нет остающихся критических дефектов / проблем, и клиент (или руководство) соглашается, что любые оставшиеся проблемы могут быть отложены

Прелесть управления этим с помощью JIRA заключается в том, что добавление выпусков, создание журналов изменений и т. Д. Довольно хорошо автоматизированы.

Answer 5

Major.Minor.BuildDateNumber.DailyBuildNumber

Major и Minor устанавливаются нами, вручную увеличивая их по своему усмотрению.

BuildDateNumber - это количество месяцев с начала проекта, умноженное на 100, плюс номер дня текущего месяца.

DailyBuildNumber увеличивается для каждой сборки после полуночи каждый день, начиная с нуля.

например. Четвертая сборка выпуска 5.2 10 июля, когда проект начался 1 января того же года, будет иметь номер версии

5.2.710.3

Все это рассчитывается для нас с помощью задачи Version в Nant .

Это позволяет сохранить уникальные номера версий, а также позволяет нам быстро рассчитать время сборки установки.

Answer 6

Мы также используем <major>.<minor>.<buildnumber>, и мы управляем этим с помощью CruiseControl / (. Net) на нашем сервере сборки. И используйте Wix и CruiseControl Config для управления основными младшими номерами - все еще увеличивайте их вручную - но номер сборки происходит автоматически на сервере сборки. Я полагаю, что вы также можете настроить правило для увеличения основного / вспомогательного уровня автоматически - нам просто хотелось бы сделать это вручную, чтобы у разработчика потребовалось сознательное мышление, когда пришло время назвать конкретный уровень выпуска.