Как обрабатывать несколько конфигураций в управлении выпуском VSTS?

Для нашего проекта мы используем Visual Studio Team Services для поддержки кода и сборки. Для этого проекта я также хочу настроить выпуск mangement. (https://www.visualstudio.com/en-us/features/release-management-vs.aspx)

Для среды Test, Staging и Production у нас есть разные файлы Web.config, которые преобразуются для конкретной среды.

Я установил его следующим образом (шаги MSBuild Build):

Существует очень строгая работа, которая создает артефакты сборки для развертывания Cloud Service ServiceConfiguration.cscfg и DeploymentPackage.cspkg(/t: Publish) и целевого теста среды (/p: TargetProfile = Test).
Артефакты публикуются с задачей сборки VSTS, чтобы включить развертывание с управлением выпуском.
После успешной ночной сборки создается релиз, артефакты загружаются и автоматически развертываются в тестовой среде.

Вопрос: релиз создан для тестовой среды вместе с Test Web.config. Каков общий подход к перемещению этой сборки в среду Staging? Для этого мне нужен Staging Web.config. Должен ли я всегда строить 3 раза и хранить эти артефакты? Это означало бы много артефактов/дисковых пространств для сборщиков, которые не будут развернуты большую часть времени.

MSDN, похоже, не дает мне ответа. Любые идеи?

Ответ 1

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

1. Настройка нескольких конфигураций в определении сборки

1.1 Откройте свое определение сборки для редактирования.

1.2 На вкладке "Переменная" отредактируйте значение переменной BuildConfiguration (добавьте эту переменную, если она не существует), так что это список разделенных запятыми различных конфигураций, которые вы хотите построить. Каждое из этих значений должно соответствовать конфигурации в исходном коде. В моем примере у меня есть три конфигурации - Dev, Test и Staging. В моем коде каждая из этих конфигураций имеет свой собственный файл преобразования web.config, определяющий разные строки подключения к базе данных и т.д.

1.3 На вкладке "Параметры" включите многоконфигурацию с правой стороны.

1.4 В настройках многоконфигурации введите имя переменной BuildConfiguration в поле Multipliers. Это должно точно совпадать с именем переменной, которую вы задали на шаге 1.2. В моем примере вы можете видеть, что я также проверил флажок Parallel, и это работает нормально. Я думаю, если у вас возникнут проблемы, вы можете снять этот флажок.

1.5 На вкладке "Задачи" выберите задачу "Сборка".

1.6 В параметрах для задачи Build вам необходимо обновить поле MSBuild Arguments, чтобы выходной каталог включал переменную BuildConfiguration. Таким образом, задача Build создаст отдельный выходной каталог для каждой конфигурации. В этом контексте переменная BuildConfiguration указана как $(BuildConfiguration).

1.7 На вкладке "Задачи" выберите задачу "Опубликовать артефакт".

1.8 Добавьте переменную BuildConfiguration в путь, указанный в поле Path to Publish. Это снова означает, что когда артефакты отбрасываются для процесса Release, чтобы их собрать, каждая конфигурация имеет свою собственную подпапку. Опять же, в этом контексте переменная BuildConfiguration указана как $(BuildConfiguration).

1.9 Измените значение поля Artifact Name на переменную BuildConfiguration - еще раз, здесь $(BuildConfiguration).

2. Настроить определение выпуска для нескольких конфигураций

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

2,1. Откройте свое определение выпуска для редактирования.

2,2. На вкладке "Окружения" выберите среду, которую вы хотите настроить. В этом примере показано, как я настраиваю среду Dev.

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

2,3. Выберите задачу "Копировать файлы".

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

2,5. Идем дальше и настраиваем остальные параметры среды в соответствии с вашими требованиями - машину (сервер, на которую вы публикуете файлы) и т.д. Поле Destination Folder, по крайней мере, обязательно будет отличаться для каждой из ваших сред. Поле Machines также может меняться.

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

Я надеюсь, что это поможет кому-то еще, чтобы это работало!

UPDATEРешение, описанное выше, похоже, работает отлично. Однако, поскольку число сред, в которых я развертываю одно из наших приложений, выросло (в настоящее время на 10 и подсчитывается), я начал искать альтернативный способ преобразования Web.config для каждой среды, учитывая, что только фактическое Разница между средами - это строка подключения к базе данных.

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

Это намного более аккуратно. Наш код теперь содержит только одно преобразование Web.config, наш процесс сборки теперь намного быстрее, поскольку мы не создаем сборку для каждой среды, а пароли базы данных и т.д. Сохраняются в зашифрованном виде как переменные в конфигурации Release.

Суть того, что я сделал, подробно описана здесь, но в то время как автор этой статьи использует инструмент, называемый Tokenizer, установленный на нем -premises TFS box, я использовал очень приятную задачу Tokenization из Marketplace в моей конфигурации Release, чтобы преобразовать маркеры, которые я использовал в моем Файл Web.config.