Развертывание конкретной сборки

Статья
07/13/2023

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

Этот раздел является частью серии учебников, основанных на требованиях к развертыванию на предприятии вымышленной компании Fabrikam, Inc. В этой серии учебников используется пример решения диспетчера контактов для представления веб-приложения с реалистичным уровнем сложности, включая приложение ASP.NET MVC 3, службу Windows Communication Foundation (WCF) и проект базы данных.

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

Обзор задачи

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

Рассмотрим сценарий непрерывной интеграции (CI), описанный в предыдущем разделе Создание определения сборки, поддерживающее развертывание. Вы создали определение сборки в Team Foundation Server (TFS) 2010. Каждый раз, когда разработчик проверяет код в TFS, командная сборка будет создавать код, создавать веб-пакеты и скрипты баз данных в процессе сборки, выполнять любые модульные тесты и развертывать ресурсы в тестовой среде. В зависимости от политики хранения, настроенной при создании определения сборки, TFS сохранит определенное количество предыдущих сборок.

В зависимости от политики хранения, настроенной при создании определения сборки, T F S сохранит определенное количество предыдущих сборок. =======

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

Для этого необходимо сообщить Microsoft Build Engine (MSBuild), где найти веб-пакеты и скрипты базы данных, созданные определенной сборкой.

Переопределение свойства OutputRoot

В примере решения файл Publish.proj объявляет свойство с именем OutputRoot. Как следует из названия, это корневая папка, содержащая все, что создает процесс сборки. В файле Publish.proj видно, что свойство OutputRoot относится к корневому расположению для всех ресурсов развертывания.

Примечание

OutputRoot — это часто используемое имя свойства. Файлы проектов Visual C# и Visual Basic также объявляют это свойство для хранения корневого расположения для всех выходных данных сборки.

<PropertyGroup>
  <!--This is where the .deploymanifest file will be written to during a build-->    
  <_DbDeployManifestPath>
    $(OutputRoot)ContactManager.Database.deploymanifest
  </_DbDeployManifestPath>    
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Mvc Web project -->
  <_ContactManagerDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Mvc_Package\
  </_ContactManagerDest>
  
  <!-- The folder where the .zip and .cmd file will be located for 
                ContactManager.Service Web project -->
   <_ContactManagerSvcDest>
    $(OutputRoot)_PublishedWebsites\ContactManager.Service_Package\
  </_ContactManagerSvcDest>
  
  <!-- ... -->
</PropertyGroup>

Если вы хотите, чтобы файл проекта развертывал веб-пакеты и скрипты базы данных из другого расположения, например выходных данных предыдущей сборки TFS, необходимо просто переопределить свойство OutputRoot . Необходимо задать для свойства соответствующую папку сборки на сервере Team Build. Если вы запускали MSBuild из командной строки, можно указать значение OutputRoot в качестве аргумента командной строки:

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\

На практике, однако, вы также хотите пропустить целевой объект сборки — нет смысла создавать решение, если вы не планируете использовать выходные данные сборки. Это можно сделать, указав целевые объекты, которые нужно выполнить в командной строке:

msbuild.exe Publish.proj /p:TargetEnvPropsFile=EnvConfig\Env-Dev.proj 
  /p:OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
  /target:GatherPackagesForPublishing;PublishDBPackages;PublishWebPackages

Однако в большинстве случаев необходимо встроить логику развертывания в определение сборки TFS. Это позволяет пользователям с разрешением сборки очереди активировать развертывание из любой установки Visual Studio с подключением к серверу TFS.

Создание определения сборки для развертывания конкретных сборок

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

В этом случае вы не хотите, чтобы определение сборки на самом деле выполняло что-либо. Вы хотите, чтобы оно выполняло логику развертывания в файле настраиваемого проекта. Файл Publish.proj содержит условную логику, которая пропускает целевой объект сборки , если файл выполняется в team build. Это делается путем оценки встроенного свойства BuildingInTeamBuild , которое автоматически получает значение true при запуске файла проекта в Team Build. В результате можно пропустить процесс сборки и просто запустить файл проекта, чтобы развернуть существующую сборку.

Создание определения сборки для запуска развертывания вручную

В Visual Studio 2010 в окне Командная Обозреватель разверните узел командного проекта, щелкните правой кнопкой мыши Сборки выберите команду Создать определение сборки.
На вкладке Общие присвойте определению сборки имя (например, DeployToStaging) и необязательное описание.
На вкладке Триггер выберите Вручную — при регистрации новая сборка не активируется.
На вкладке Сборка по умолчанию в поле Копирование выходных данных сборки в следующую папку удаления введите UNC-путь к папке перетаскивания (например, \TFSBUILD\Drops).

$На вкладке Сборка по умолчанию в поле Копирование выходных данных сборки в следующую папку удаления введите путь к папке перетаскивания (например, \TFSBUILD\Drops).$
На вкладке Процесс в раскрывающемся списке Файл процесса сборки оставьте значение DefaultTemplate.xaml выбранным . Это один из шаблонов процесса сборки по умолчанию, который добавляется во все новые командные проекты.
В таблице Параметры процесса сборки щелкните строку Элементы сборки и нажмите кнопку с многоточием .
В диалоговом окне Элементы для сборки нажмите кнопку Добавить.
В раскрывающемся списке Элементы типа выберите Файлы проекта MSBuild.
Перейдите к расположению файла пользовательского проекта, с помощью которого вы управляете процессом развертывания, выберите файл и нажмите кнопку ОК.
В диалоговом окне Элементы для сборки нажмите кнопку ОК.
В таблице Параметры процесса сборки разверните раздел Дополнительно .
В строке Аргументы MSBuild укажите расположение файла проекта для конкретной среды и добавьте заполнитель для расположения папки сборки:
```
/p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
OutputRoot=PLACEHOLDER
```
Примечание

Вам потребуется переопределять значение OutputRoot каждый раз, когда вы ставите сборку в очередь. Это рассматривается в следующей процедуре.
Нажмите Сохранить.

При активации сборки необходимо обновить свойство OutputRoot , чтобы указать на сборку, которую требуется развернуть.

Развертывание определенной сборки из определения сборки

В окне Командная Обозреватель щелкните правой кнопкой мыши определение сборки и выберите пункт Очередь новой сборки.
В диалоговом окне Сборка очереди на вкладке Параметры разверните раздел Дополнительно .
В строке Аргументы MSBuild замените значение свойства OutputRoot расположением папки сборки. Пример:
```
/p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
   OutputRoot=\\TFSBUILD\Drops\DeployToTest\DeployToTest_20120228.3\
```
Примечание

Обязательно добавьте косую черту в конце пути к папке сборки.
Щелкните Очередь.

При постановке сборки в очередь файл проекта развертывает скрипты базы данных и веб-пакеты из папки удаления сборки, указанной в свойстве OutputRoot .

Заключение

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

Дополнительные материалы

Дополнительные сведения о создании определений сборки см. в разделах Создание базового определения сборки и Определение процесса сборки. Дополнительные рекомендации по постановке в очередь сборок см. в разделе Очередь сборки.

Назад Вперед

Поделиться через