Я работаю в компании по разработке продуктов. Сначала мы делаем внутренние выпуски, а затем публичный выпуск. Мне было интересно, как другие компании-разработчики продуктов управляют выпуском? Как вы сообщаете номер выпуска? Отметьте элемент управления источником?
Управление релизами - лучшая практика
Ответ 1
Мы используем SubVersion, где теги и ветки дешевы для создания.
Что касается релизов, мы следуем этому соглашению:
(Основной выпуск). (Малая версия). (Патч-релиз). (Версия SVN)
- Патч Release = исправления ошибок
- Незначительный выпуск = двоичная совместимость/ интерфейс совместим
- Основной релиз = включает разрывы изменения.
Это имеет смысл? Если вам нужна дополнительная информация, добавьте комментарий, и я отредактирую свое сообщение, чтобы уточнить.
Ответ 2
Я создал аналогичный вопрос, но я хотел бы добавить к этому: я настоятельно рекомендую использовать что-то вроде Jira для управления циклом выпуска. Вы можете связать коммиты с запросами/проблемами/ошибками, а затем пометить их как часть выпуска.
В частности, если вы хотите знать, как управлять хорошим циклом выпуска, взгляните на то, как это делает Фонд Apache, потому что они сводят его к науке. Например, здесь дорожная карта для выпусков в проекте Mahout.
Наряду с рабочей системой, которая отслеживает проблемы и связывает их в пакет выпуска, вы захотите начать интеграцию с постоянной интеграцией (я использовал CruiseControl и Hudson) и модульные тесты, чтобы управлять циклом сборки наряду со всем остальным.
Ответ 3
Я работал в качестве специализированного поставщика программного обеспечения, который в конечном итоге превратился в поставщика решений, когда клиенты решили, что они не хотят внедрять свои собственные callcenters и веб-сайты.
В этой среде у каждого крупного клиента была возможность настроить некоторые аспекты работы системы. Таким образом, у разработки был основной продукт с компонентами, общими для всех контрактов, и отдельными веткими для каждого клиента (некоторые клиенты нуждались в незначительных настройках, другие - в крупной интеграции с другими системами).
Это работало нормально, пока бизнес не рос, а количество веток не расширялось, часто для того, чтобы приспособиться к действительно хромым изменениям. В какой-то момент я думаю, что у них было что-то вроде 15 различных активных версий одной и той же кодовой базы... что сделало вещи действительно негибкими и трудными для поддержки.
Не делайте то, что мы сделали - сделайте ваши релизы масштабными!
Ответ 4
Как говорили другие, лучший способ справиться с управлением realeases - разветвление. Я настоятельно рекомендую взглянуть на Руководство по ветвлению TFS (http://tfsbranchingguideii.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=20785), в котором объясняется несколько подходов к созданию структуры ветки в зависимости от размера ваши проекты и различные способы предоставления вашего программного обеспечения конечным пользователям (основные выпуски, пакеты обновления, исправления). Большинство из них не относятся к TFS, поэтому вы можете применить его к большинству других систем управления версиями.
Ответ 5
В моей компании, когда релиз готов, мы создаем ветку для основных/младших номеров релизов, называемых как-то вроде 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)
| |
. .
. .
. .
Ответ 6
Мы используем SVN и создаем две ветки для каждой версии. Один из них - это тег исходного кода, который используется для создания этой версии, а другой - новый импорт фактических выпущенных двоичных файлов. Это важно, потому что (независимо от того, сколько вы пытаетесь сделать машины двух разработчиков одинаковыми или пытаться поддерживать стабильную машину сборки) неизбежно, когда вы приступите к регенерации сборки X 6 месяцев вниз, вы обнаружите, что что-то изменился, и результат двоичный, который является результатом, несколько отличается.
Незначительные исправления производятся в ветвях, скопированных из ветки источника выпуска, и объединены в магистраль. Небольшую версию можно легко сделать, скопировав ветвь источника выпуска в новую ветку и сгладив ее, в зависимости от того, какие исправления необходимы.
Основная работа выполняется в ветвях, скопированных из ствола, и завершается, когда они завершены. Затем из багажника могут быть сделаны основные выпуски.
Ответ 7
Ответ на основе структуры ITIL (более или менее равный другим).
ITIL классифицирует выпуски в 3-х группах: основной выпуск программного обеспечения, небольшая версия программного обеспечения и исправления программного обеспечения.
Из книг ITIL:
• Основное программное обеспечение. Релизы и обновления оборудования, обычно содержащие большие области новых функций, некоторые из которых могут сделать промежуточные исправления проблем избыточными. Основное обновление или выпуск обычно заменяет все предыдущие незначительные обновления, релизы и исправления.
• Незначительное программное обеспечение. Релизы и обновления оборудования, обычно содержащие небольшие улучшения и исправления, некоторые из которых, возможно, уже были выпущены в качестве исправлений. Небольшое обновление или выпуск обычно заменяет все предыдущие исправления.
• Чрезвычайные программные и аппаратные исправления, обычно содержащие поправки к небольшому числу известных проблем.
Итак, после этого вы должны иметь:
Майор: v1, V2, v3 и т.д.
Малый: v1.1, V2.1 и т.д.
Чрезвычайная ситуация: v1.1.1, V2.1.1 и т.д.
Ответ 8
Последующие действия в отношении кота-ответа относительно TFS. Существует новый URL-адрес с некоторыми обновлениями для VS2010 и VS11