В распределенной архитектуре почему сложно управлять версиями?

Question

Я вижу это снова и снова. Менеджер тестирования UAT хочет, чтобы новая сборка была готова к тестированию к пятнице. Один из первых вопросов, заданных на собрании перед тестированием, - «против какой версии я буду тестировать?» (это справедливый вопрос). Комната замолкает, а потом кто-то снова скажет: «У всех сборок есть своя версия, просто щелкните правой кнопкой мыши и посмотрите свойства ...».

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

Я видел решения, в которых версия различных областей системы, хранящихся в хранилище данных, затем отображалась в блоке about основного приложения. Проблема в том, что это необходимо поддерживать.

Какие решения вы видели, чтобы обойти эту проблему?

EDIT. Распределенная система включает в себя VB6, Classic ASP, VB.Net, C #, веб-сервисы (по департаментам, какую версию мы используем?), SQL Server 2005.

Answer 1

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

В таких ситуациях вы должны сопоставить все ваши различные сборки компонентов в системную версию. Вы говорите что-то вроде «Версия 1.5 системы состоит из Foo.Bar.dll v1.4.6 и Baz.Qux.dll v2.6.7 и (и т. Д.)». Черт, в распределенной системе вам могут потребоваться разные версии для каждой из ваших служб, которые сами по себе могут состоять из разных версий .dll. Например, вы можете сказать: «Версия 1.5 системы состоит из службы Foo v1.3, которая состоит из Foo.dll v1.9.3 и Bar.dll v1.6.9, и службы Bar v1.9, которая состоит из Baz.dll v1.8.2 и Qux.dll v1.5.2 и (и т. д.) ".

Подобные действия обычно выполняются архитектором программного обеспечения и / или менеджером по сборке в вашей организации.

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

Answer 2

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

Одним из преимуществ распределенной архитектуры является то, что мы получаем огромный потенциал для повторного использования, создавая службы и публикуя их интерфейсы в той или иной форме. Это означает, что выпуски клиентского приложения не обязательно тесно синхронизированы с выпусками базовых сервисов. Таким образом, может быть выпущена новая версия бизнес-приложения, которое использует тот же старый надежный сервис, который использовался в течение года. Как мы тогда применим один тег выпуска в этом случае?

Тем не менее, это справедливый вопрос, но тот, который требует нетривиального ответа, чтобы быть осмысленным.

Answer 3

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

Answer 4

Мы используем .NET и Subversion. Все наши сборки приложений имеют общий номер версии, полученный из обновленных вручную номеров старших и младших версий и номера версии Subversion (<major>.<minor>.<revision>). У нас есть задача предварительной сборки, которая обновляет этот номер версии в общем файле AssemblyVersionInfo.vb. Затем, когда тестировщики запрашивают номер версии, мы можем либо дать им полный номер из трех частей, либо просто пересмотреть версию Subversion. Используемые нами библиотеки не меняются, или изменение не относится к тестеру.

Answer 5

Не использовать нумерацию версий на основе сборки для чего-либо, кроме внутренних ссылок. Когда менеджер UAT задает вопрос, вы говорите «Пятница *».

Единственная уловка - обеспечить надежную маркировку в вашем контроле источников.

* вставьте соответствующую дату / метку здесь