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

Джейсон Ли

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

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

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

Обзор задачи

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

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

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

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

Для этого необходимо сообщить подсистеме сборки Майкрософт (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 в окне Team Explorer разверните узел команды, щелкните правой кнопкой мыши Сборки и выберите Создать новое определение сборки.
На вкладке "Общие " укажите определение сборки (например, DeployToStaging) и необязательное описание.
На вкладке "Триггер" выберите "Вручную" — фиксации изменений не инициируют новую сборку.
На вкладке "Сборка по умолчанию" в поле Скопировать результаты сборки в следующую папку сброса введите путь универсального соглашения о именовании (UNC) к вашей папке сброса (например, \TFSBUILD\Drops).
На вкладке "Процесс" в раскрывающемся списке файла процесса сборки оставьте выбранным DefaultTemplate.xaml. Это один из шаблонов процессов сборки по умолчанию, которые добавляются во все новые проекты команд.
В таблице параметры процесса сборки щелкните строку "Элементы для сборки" и нажмите кнопку с тремя точками.

В таблице параметров процесса сборки щелкните строку "Элементы для сборки" и затем нажмите кнопку с многоточием.
В диалоговом окне "Элементы для сборки" нажмите кнопку "Добавить".
В раскрывающемся списке "Элементы типа" выберите файлы проекта MSBuild.
Перейдите к расположению пользовательского файла проекта, с помощью которого вы управляете процессом развертывания, выберите файл и нажмите кнопку "ОК".
В диалоговом окне "Элементы для сборки" нажмите кнопку "ОК".
В таблице параметров процесса сборки разверните раздел "Дополнительно ".
В строке аргументов MSBuild укажите расположение файла проекта для конкретной среды и добавьте заполнитель для расположения папки сборки:
```
/p:TargetEnvPropsFile=EnvConfig\Env-Stage.proj;
OutputRoot=PLACEHOLDER
```
Замечание

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

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

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

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

Не забудьте включить косую черту в конце пути к папке сборки.
Нажмите очередь.

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

Conclusion

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

Дальнейшее чтение

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

Назад Далее

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2023-07-13