Управление релизами - лучшая практика

Я работаю в компании по разработке продуктов. Сначала мы делаем внутренние выпуски, а затем общедоступные. Мне было интересно, как другие компании по разработке продуктов управляют своим выпуском? Как вы даете номер релиза? Отметить источник контроля?

Ответы на вопрос(8)

Что касается релизов, мы следуем этому соглашению:

(Основной выпуск). (Незначительный выпуск). (Выпуск исправления). (Редакция SVN)

Patch Release = исправление ошибокНезначительный выпуск = двоичный код / интерфейсMajor Release = включает в себя критические изменения.

Имеет ли это смысл? Если вам нужна дополнительная информация, добавьте комментарий, и я 'Я буду редактировать мой пост, чтобы уточнить.

 Bob Aman16 окт. 2009 г., 21:59
я не уверен, что ябуду называть ветки и тэги Subversion дешевыми, чтобы создавать ... по крайней мере, не после того, как использовал Git.
 Owen Blacker22 мар. 2011 г., 18:24
Что сказал Боб - мы'собирается двигатьсяот диверсияв Git, отчасти потому, что ветвление и тегирование в Git намного дешевле, чем в SVN.whygitisbetterthanx.com хорошее сравнение нескольких VCS, хотя с очевидным предпочтением Git.

ыми обновлениями для VS2010 и VS11.

http://vsarbranchingguide.codeplex.com/releases

когда релиз готов, мы создаем ветку для номеров старшего / младшего релиза, которая называется что-то вродеR_2_1, Первоначальный выпуск выполняется путем создания ветви или метки моментального снимка сразу после этого, называемойR_2_1_0, Когда файлы QA сообщают об ошибках в выпуске, изменения кода вносятся вR_X_Y ветвь, а затемR_2_1_1 Ветка создана, чтобы отметить этот выпуск. Итак, дерево выглядит так:

Mainline
|
|- R_2_1
|  |
|  |-R_2_1_0 (locked)
|  |
|  |
|  |-R_2_1_1 (locked)
|  |
.  .
.  .
.  .

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

Особенно,Если вы хотите знать, как управлять хорошим циклом выпуска, взгляните на то, как это делает Apache Foundation, потому что они относятся к науке., Например, здесьсдорожная карта для релизов в проекте Mahout.

Наряду с работающей системой, которая отслеживает проблемы и объединяет их в пакет выпуска, вы захотите начать интегрировать это с вашей непрерывной интеграцией (ямы использовали и CruiseControl и Hudson), и модульные тесты, чтобы ваш цикл сборки управлялся вместе со всем остальным.

который в итоге превратился в поставщика решений, когда клиенты решили, что они неНе хочу внедрять свои колл-центры и сайты.

В этой среде каждый крупный клиент имел возможность настроить некоторые аспекты работы системы. Таким образом, разработка имела основной продукт с компонентами, общими для всех контрактов, и отдельные филиалы для каждого клиента (некоторые клиенты нуждались в незначительных изменениях, другие - в значительной интеграции с другими системами).

Это работало нормально, пока бизнес не вырос и не расширилось число филиалов, часто для того, чтобы приспособиться к действительно неудачным изменениям. В какой-то момент я думаю, что у них было что-то вроде 15 разных активных версий одной и той же кодовой базы ... что делало вещи действительно негибкими и трудными для поддержки.

Дон»делай то, что мы делали - делай свои релизы масштабными!

лучший способ справиться с управлением релизами - это ветвление. Я настоятельно рекомендую взглянуть на Руководство по ветвлению TFS (http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785), который объясняет несколько подходов к созданию структуры филиала в зависимости от размера ваших проектов и различных способов предоставления вашего программного обеспечения конечным пользователям (основные выпуски, пакеты обновления, исправления). Большинство из них не относится к TFS, поэтому вы можете применять его к большинству других систем контроля версий.

основанный на структуре ITIL (этоболее или менее равные другим).

ITIL классифицирует выпуски по 3 группам: основной выпуск программного обеспечения, второстепенный выпуск программного обеспечения и экстренные исправления программного обеспечения.

Из книг ITIL: •

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

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

Экстренные программные и аппаратные исправления, обычно содержащие исправления для небольшого числа известных проблем

Итак, после этого вы должны иметь:

Major: v1, V2, v3 и т. Д.

Незначительные: v1.1, v2.1 и т. Д.

Аварийная ситуация: v1.1.1, V2.1.1 и т. Д.

 SQLMason12 авг. 2015 г., 19:35
Ваш вопрос по теме наITIL Stackexchange

тег исходного кода, использованного для сборки этого выпуска, а второй - новый импорт фактически выпущенных двоичных файлов. Это важно, потому что (независимо от того, сколько вы пытаетесь сделать двух разработчиков " машины одинаковы или стараются поддерживать стабильную сборочную машину) неизбежно, когда вы попытаетесь восстановить сборку X через 6 месяцев, вы обнаружите, что что-то изменилось, а получаемый двоичный файл немного отличается.

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

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

Ваш ответ на вопрос