Варианты управления и сборки продукта - PullRequest
0 голосов
/ 13 мая 2009

Мы приближаемся к первоначальному выпуску нового продукта в нашей компании, и я пытаюсь определить наилучший метод управления версиями всех различных компонентов и сопоставить эти компоненты с версией нашего программного обеспечения в отделе маркетинга. По разным причинам маркетинг определил, что начальный выпуск нашего продукта будет 10.1, однако все компоненты будут изначально начинаться с 1.0.0. Благодаря обычным исправлениям ошибок, исправлениям и дальнейшей разработке, различные компоненты больше не будут иметь одинаковый номер версии, поэтому, когда отдел маркетинга решит, что пришло время для версии 10.2, он может содержать 1.1.54, 1.2.32, 1.8.2, и т. д. Очевидно, что я мог бы использовать простую электронную таблицу, но это не совсем удобный для пользователя метод, и у сотрудников службы технической поддержки есть проблемы с перекрестными ссылками на версии компонентов (клиент действительно знает только о версии 10.1, 10.2 и т. д.).

Есть ли для этого более "профессиональный" метод или простая электронная таблица - лучший вариант?

Ответы [ 3 ]

2 голосов
/ 29 декабря 2009

Основной принцип, который я бы предложил: используйте самую простую из возможных схем.

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

Когда вы делаете релиз, увеличиваете основной / вспомогательный номер версии, а затем ставьте его на всех ваших компонентах. Таким образом, в версии 10.1 все ваши сборки будут иметь номера версий 10.1.xx.yy

Тогда, если вы действительно хотите усложнить ситуацию с разными версиями в выпуске (например, для небольших исправлений / обновлений, разных пользовательских вариантов или только для внутренних ежедневных сборок или сборок CI), тогда используйте поля xx.yy. (Во многих случаях вы можете заставить компилятор автоматически заполнять эти два поля, например, датой / временем компиляции).

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

редактировать: P.S. Даже если компонент не изменяется, перестройте его с новым номером версии. Попытка отследить сто несинхронизированных номеров версий - это кошмар, которого можно избежать.

0 голосов
/ 13 мая 2009

Почему бы не оставить все компоненты с их «случайными» номерами версий и создать один супер тег / ярлык с маркетинговой версией, охватывающей все компоненты? Это позволяет вам обновлять компоненты между маркетинговыми сборками и увеличивать их версии (без необходимости переходить к 10.1.001, 10.1.002, которые могут быть видны клиенту), а также отслеживать маркетинговую сборку. Кроме того, что произойдет, если вы обновите некоторые компоненты для следующей маркетинговой сборки, но не другие? Вам нужно собрать эти компоненты только для обновления номера версии?

В зависимости от системы управления версиями вы сможете легко создать выпуск с указанным именем / версией, который содержит все эти компоненты в разных версиях.

Вам также нужно просто обновить один файл свойств с номером маркетинговой сборки, чтобы он отображался на всех экранах, заставках, панелях инструментов и т. Д. Если у вас нет такой конфигурации, вы можете захотеть перейти на такую ​​систему. Это позволяет легко изменять видимый номер клиента, сохраняя при этом все номера сборки компонентов. Кроме того, что происходит, когда маркетинг определяет, что следующая версия будет не 10.2, а «Багровым?»

0 голосов
/ 13 мая 2009

В местах, где я работал, мы заставляли номер версии программного обеспечения соответствовать официальному, общедоступному (т. Е. Маркетинговому) номеру выпуска: если они хотели выпустить «10.1», то это то, что мы устанавливаем версию программного обеспечения ресурс, как часть сборки выпуска.

...