Сборки управления версиями распределенного приложения с горячими исправлениями

Question

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

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

Наше программное обеспечение для отслеживания проблем содержит номер версии для всего продукта.Если текущая версия 1.4.5 и требуется исправление, проблемы для исправления должны быть выпущены с версией 1.4.6.Все сборки, на которые повлияли исправления для 1.4.6, имеют версию 1.4.6.Если мы распространим только эти файлы, то в итоге получим некоторые файлы версии 1.4.5, а некоторые - 1.4.6.

Решением могло бы быть перестроение и выпуск всего приложения как версии 1.4.6, но для этого потребовалось бы перераспределить несколько компонентов на нескольких компьютерах и привести к ненужному простою компонентов, которые фактически не менялись.

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

Answer 1

Вы задаете интересный вопрос.

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

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

Это может быть излишеством, поэтому альтернативой было бы упростить управление версиями.Например, вы могли бы зарезервировать часть своего номера версии для указания исправлений.Например, если 1.4.5.0 является официальным выпуском, исправлением будет 1.4.5.1, и это легко понять как часть официального выпуска 1.4.5.

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