Каков наилучший способ создания версии многокомпонентного проекта?

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

Кто-нибудь нашел простой способ сделать это, кроме как перечислить каждый отдельно?

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

У нас есть «версия выпуска системы», которая представляет собой стандартный номер версии, который описывает конкретную конфигурацию компонентов, а затем в отдельном файле перечислены версии отдельных компонентов для этой конкретной версии системы. Клиенты говорят 5.2.1, но мы можем посмотреть индивидуальную сборку, если это необходимо. Обычно для основного выпуска мы синхронизируем все отдельные версии, чтобы все снова создавалось из одного и того же номера ветви.

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

Хороший известный шаблон для управления версиями от Microsoft :

major version.minor version.build number.revision

Например, вы можете видеть, что файлы DLL на платформе .NET имеют версии вроде 2.0.3600.1 или что-то в этом роде.

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

Будьте осторожны с версионированием, оно может вас убить :-) Не пытайтесь усложнить ситуацию.

Я думаю, что следующий подход может помочь вам:

Версия каждого компонента индивидуально с любой версионной схемой, которую вы хотите. Из ваших комментариев я понимаю, что у вас есть VCS на месте. Я также предполагаю, что у каждого компонента есть файл, в котором хранится его версия (верно?). Раз в день / неделю (в зависимости от того, что лучше для вашей команды) добавьте тег к одной из самых последних ревизий в VCS, который помечает эту ревизию как последнюю официальную ревизию (и дополнительно увеличивает номер супер-ревизии). Теперь вы можете запросить VCS для ревизий с этим тегом и затем найти версию компонентов в этой официальной сборке.

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

Если вы хотите сделать его еще более привлекательным, сделав пометки, вы можете посмотреть файлы, принадлежащие каждому компоненту, учитывая, что вы можете определить файлы, принадлежащие определенному компоненту. Если что-то изменилось, увеличьте версию для этого конкретного компонента. Альтернатива - сделать это вручную. Другой альтернативой является сочетание ветвления и слияния с отслеживанием версий.

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

Если вы следуете чему-то похожему на шаблон Microsoft:

major-version.minor-version.build-number.revision

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

Если вы следуете шаблону, похожему на этот:

Major-Version.Minor-Version.Build-Number

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

Целые книги написаны о версии программного обеспечения.

Вот подход, который я использую.

Каждая часть имеет версию в виде:

major.minor.developmental

Каждый из них является числом, начиная с 0.

Для официального выпуска (то есть для клиентов) часть разработки всегда должна быть 0 в соответствии с политикой.

Основные увеличивается на основе маркетингового решения.

Незначительное увеличивается за счет выпуска наборов функций на рынок.

Пример:

• Я начинаю разработку нового компонента, поэтому номер моей версии будет 0.0.1. Когда я передаю свой стол своим коллегам, например, для внутреннего тестирования, число разработки увеличивается до 0.0.2, 0.0.3 и так далее.

• Я выпускаю эту новую вещь на рынок как 1.0.0, где единственным разрешенным изменением с конца разработки на выпуск было изменение номера версии (например, 0.0.43 -> 1.0.0).

• Некоторые новые функции должны быть добавлены. Я начинаю работу с базовой версией 1.0.0, добавляя эти функции, поэтому версии, которые я выпускаю для тестирования коллегам, - это 1.0.1, 1.0.2 и так далее.

• Следующие функции выпущены на рынок как 1.1.0.

• Маркетинг решает, что следующая большая вещь будет действительно большой, поэтому она выйдет как 2.0.0. Я начинаю работу над 1.1.1, продвигаюсь через 1.1.x и выпускаю как 2.0.0.

И так цикл повторяется.

Этот подход для каждого компонента дает вам возможность проследить происхождение.

Внутри вашей системы управления версиями (и объектами) используйте ветки и теги (метки, независимо от вашей терминологии дня) для управления разработкой.

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

Вероятно, ваш процесс выпуска потребует тщательного обдумывания. Использование этого подхода включает некоторые ручные шаги, и это может быть нежелательно - все зависит от того, как ваша система сборки вставляет номера версий в конечный объект. Для большого количества встроенного кода, где номера версий являются просто именованными номерами (например, #defined в C-коде), у вас нет выбора, кроме как все это делать вручную. Платформы для настольных компьютеров с приятным графическим интерфейсом часто делают все это более дружелюбным.

Резюме

Для меня единственный надежный способ версии программного обеспечения - использовать хеш или идентификатор набора изменений из вашей системы контроля версий.

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

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

Пример из личного опыта

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

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

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

Из этого я легко мог видеть, что они модифицировали Library3 и не зафиксировали эти изменения в хранилище, поэтому они используют код, который не контролируется. Я также мог бы сравнить хэши с моей текущей тестовой системой, таким образом, я мог бы определить, что они вернули (скажем) Library1 к более старой версии.

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

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

Примечание. Эта система действительно жизнеспособна только в том случае, если вы используете систему контроля версий, в которой определенный хеш гарантированно приведет к тому же набору файлов в вашем рабочем каталоге (например, git и mercurial), если данный рабочий каталог может содержать смесь файлов. и каталоги из нескольких ревизий (например, svn), тогда все ставки отключены относительно состояния рабочего каталога, и этот метод не будет работать вообще.