Создание определения сборки, поддерживающего развертывание

Джейсон Ли

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

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

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

Обзор задачи

Определение сборки — это механизм, который управляет тем, как и когда выполняются сборки для командных проектов в TFS. Каждое определение сборки указывает:

• Элементы, которые вы хотите создать, например файлы решения Visual Studio или пользовательские файлы проекта Microsoft Build Engine (MSBuild).
• Критерии, определяющие, когда должна выполняться сборка, например ручные триггеры, непрерывная интеграция (CI) или закрытые проверка входы.
• Расположение, в которое Командная сборка должна отправлять выходные данные сборки, включая артефакты развертывания, такие как веб-пакеты и скрипты баз данных.
• Количество времени, в течение которых должна храниться каждая сборка.
• Различные другие параметры процесса сборки.

Примечание

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

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

При активации сборки необходимо выполнить следующие действия:

• Во-первых, командная сборка должна создать решение. В рамках этого процесса командная сборка вызовет конвейер веб-публикации (WPP) для создания пакетов веб-развертывания для каждого проекта веб-приложения в решении. Командная сборка также будет выполнять все модульные тесты, связанные с решением.
• Если сборка решения завершается сбоем, Командная сборка не должна предпринимать никаких дальнейших действий. Сбои модульного теста следует рассматривать как сбой сборки.
• Если сборка решения завершается успешно, командная сборка должна запустить пользовательский файл проекта, который управляет развертыванием решения. В рамках этого процесса командная сборка вызовет средство веб-развертывания служб IIS (веб-развертывание) для установки упакованных веб-приложений на целевых веб-серверах, а также вызовет служебную программу VSDBCMD.exe для запуска скриптов создания базы данных на целевых серверах баз данных.

На этом примере показан процесс:

Пример решения диспетчера контактов включает пользовательский файл проекта MSBuild Publish.proj, который можно запустить из MSBuild или Team Build. Как описано в разделе Основные сведения о процессе сборки, этот файл проекта определяет логику, которая развертывает веб-пакеты и базы данных в целевой среде. Файл содержит логику, которая пропускает процесс сборки и упаковки, если он выполняется в Team Build, оставляя только задачи развертывания для выполнения. Это связано с тем, что при автоматизации развертывания таким образом обычно требуется убедиться, что решение успешно выполняет сборку и проходит все модульные тесты до начала процесса развертывания.

В следующем разделе объясняется, как реализовать этот процесс путем создания нового определения сборки.

Примечание

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

Кто выполняет эту процедуру?

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

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

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

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

1. В Visual Studio 2010 в окне Team Обозреватель разверните узел командного проекта, щелкните правой кнопкой мыши сборку и выберите пункт Создать определение сборки.

   

2. На вкладке Общие присвойте определению сборки имя (например, DeployToTest) и необязательное описание.

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

4. На вкладке Сборка по умолчанию в поле Копировать выходные данные сборки в следующую папку удаления введите UNC-путь к папке удаления (например, \TFSBUILD\Drops).

   

   Примечание

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

5. На вкладке Процесс в раскрывающемся списке Файл процесса сборки оставьте выбранным defaultTemplate.xaml . Это один из шаблонов процесса сборки по умолчанию, который добавляется во все новые командные проекты.

6. В таблице Параметры процесса сборки щелкните строку Элементы для сборки и нажмите кнопку с многоточием .

   

7. В диалоговом окне Элементы для сборки нажмите кнопку Добавить.

8. Перейдите к расположению файла решения и нажмите кнопку ОК.

   

9. В диалоговом окне Элементы для сборки нажмите кнопку Добавить.

10. В раскрывающемся списке Элементы типа выберите Файлы проекта MSBuild.

11. Перейдите к расположению файла пользовательского проекта, с помощью которого вы управляете процессом развертывания, выберите файл и нажмите кнопку ОК.

    

12. В диалоговом окне Элементы для сборки теперь должны отображаться два элемента. Нажмите кнопку ОК.

    

13. На вкладке Процесс в таблице Параметры процесса сборки разверните раздел Дополнительно .

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

    /p:DeployOnBuild=true;DeployTarget=Package;
       TargetEnvPropsFile=EnvConfig\Env-Dev.proj
    

    

15. В этом примере:

    1. Аргументы DeployOnBuild=true и DeployTarget=package являются обязательными при сборке решения Диспетчера контактов. Это предписывает MSBuild создавать пакеты веб-развертывания после сборки каждого проекта веб-приложения, как описано в разделе Создание и упаковка проектов веб-приложений.
    2. Аргумент TargetEnvPropsFile является обязательным при сборке файла Publish.proj . Это свойство указывает расположение файла конфигурации для конкретной среды, как описано в разделе Основные сведения о процессе сборки.

16. На вкладке Политика хранения настройте требуемое количество сборок каждого типа.

17. Нажмите Сохранить.

Помещение построения в очередь

На этом этапе вы создали по крайней мере одно новое определение сборки. Определенный процесс сборки теперь будет выполняться в соответствии с триггерами, указанными в определении сборки.

Если вы настроили определение сборки для использования CI, вы можете протестировать определение сборки двумя способами:

• Проверьте содержимое в командном проекте, чтобы активировать автоматическую сборку.
• Поставить сборку в очередь вручную.

Постановка сборки в очередь вручную

1. В окне Team Обозреватель щелкните правой кнопкой мыши определение сборки и выберите пункт Очередь новой сборки.

   

2. В диалоговом окне Сборка очереди просмотрите свойства сборки и щелкните Очередь.

   

Чтобы просмотреть ход выполнения и результат сборки независимо от того, была ли она активирована вручную или автоматически, дважды щелкните определение сборки в окне Командная Обозреватель. Откроется вкладка Сборка Обозреватель.

Здесь можно устранить неполадки со сбоем сборок. Если дважды щелкнуть отдельную сборку, можно просмотреть сводную информацию и перейти к подробным файлам журнала.

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

Примечание

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

Мониторинг процесса сборки

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

Заключение

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

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

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

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

НазадВперед