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

Джейсон Ли

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

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

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

Обзор задачи

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

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

Замечание

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

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

При активации сборки эти действия должны произойти:

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

Это иллюстрирует процесс:

Иллюстрирует приведенный выше процесс.

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

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

Замечание

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

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

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

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

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

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

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

    В Visual Studio 2010 в окне Team Explorer разверните узел проектной группы, щелкните правой кнопкой мыши

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

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

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

    На вкладке "Параметры сборки по умолчанию" в поле для ввода "Скопировать выходные данные сборки в следующую папку" укажите путь в формате универсальной системы именования (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
    

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

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

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

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

Очередь сборки

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

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

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

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

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

    В окне Team Explorer щелкните правой кнопкой мыши определение сборки и нажмите кнопку

  2. В диалоговом окне "Постановка в очередь сборки" просмотрите свойства сборки и нажмите кнопку "Поставить в очередь".

    В диалоговом окне

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

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

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

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

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

Замечание

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

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

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

Conclusion

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

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

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

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