Версии сборок распределенного приложения с оперативными исправлениями

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.)