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

Question

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

Answer 1

Мы используем SubVersion, где тэги и ветви дешевы для создания.

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

(Major Release). (Незначительный выпуск). (Патч-релиз). (SVN revision)

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

Из книг ITIL:

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

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

Major: v1, V2, v3 и т. Д.
Незначительный: v1.1, V2.1 и т. Д.
Аварийная ситуация: v1.1.1, V2.1.1 и т. Д.

Answer 6

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

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

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

Answer 7

В моей компании, когда релиз готов, мы создаем ветку для номеров старших / младших релизов, которая называется что-то вроде 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)
|  |
.  .
.  .
.  .

Answer 8

Продолжение ответа co-cat относительно TFS. Появился новый URL с некоторыми обновлениями для VS2010 и VS11

http://vsarbranchingguide.codeplex.com/releases