Стратегии поддержки Symbol Store для ночных сборок и выпуска сборок

Question

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

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

Мне также нужно иметь возможность постоянно сохранять все бета, RC и выпускать символы сборки.

После долгих исследований, я думаю, что лучший подход здесь состоит в том, чтобы иметь два сервера символов: один для ночных сборок (в которых зарегистрированы предыдущие ~ 30 сборок), а другой для постоянного хранения символов бета, RC и релиза. , Я хотел бы добавить сценарии сборки в хранилище символов, используя теги product и version для записи продукта и номера сборки. После успешной сборки сценарий будет использовать history.txt с сервера символов, чтобы определить самую старую не удаленную сборку, а затем удалить ее из хранилища символов.

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

Итак, у меня есть несколько вопросов: кажется ли это вообще разумным? Должен быть более простой способ сделать это, не нужно ли большинству организаций с сервером символов решать эту проблему?

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

Заранее спасибо за любую помощь. Я с удовольствием отвечу на любые вопросы, которые могут возникнуть у кого-либо, или предоставлю любые разъяснения.

Answer 1

Я думаю, что два отдельных магазина символов действительно будут вашим лучшим выбором. Для управления магазином для ваших ночных сборок я рекомендую взглянуть на AgeStore: http://msdn.microsoft.com/en-us/library/ff560046(v=vs.85).aspx

Answer 2

Я написал виджет в Wise Script, который запускается для каждой сборки, которая выполняет следующие действия.

Предполагая, что наша версия имеет версии 1.0.1.0

1.) Символы с 1.0.1.0 по 1.0.6.0добавляются в хранилище (5 запусков)

2.) при каждой сборке файл истории хранилища символов анализируется ...

3.) при сборке 1.0.7.0 исимволы добавлены, 1.0.1.0 символы удалены из хранилища символов.

Я в основном разбираю номер версии и, если третье место более чем на 5 меньше текущего, я анализирую идентификатор транзакции и запускаю symstore.exe del / i% TRANS_ID%

Это сокращает мои символы для ежедневных / CI-сборок до последних 5 символов сборки.

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

Если хотите, я мог бы вырезать / вставить код здесь как код установщика SMS (так же, как Wise).Я также написал похожий виджет, который хранит мой локальный архив 5 сборок.Таким образом, я не теряю место для своего локального архива для сборок CI.Я использую оба, но вы могли бы использовать либо.Оба используют простой файл .INI для навигации во время выполнения.Таким образом, я могу поместить их обоих в свою папку Jenkins / Jobs / и просто отредактировать файл .INI для каждого.Они очень легкие, поскольку .EXE - всего 161 КБ для archive_prunerator и 161 для symstore_widget, а также 4 или 5-строчный INI-файл.

AJ