Обзор

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

Подсистема Team Build основана на системе Microsoft Build Engine (MS-Build) и позволяет извлекать исходный код для сборки, компиляции решения и (при необходимости) для запуска в процессе сборки инструментов модульного тестирования и анализа статического кода. Вы также можете поместить результат сборки на заданном общем ресурсе.

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

Архитектура

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

Физическая архитектура

Физическая архитектура Team Build состоит из следующих компонентов:

• Мастер New Team Build Type Creation Wizard - клиентский компонент для создания новых типов сборок; доступен из Team Explorer.
• Обозреватель Team Build - клиентский компонент, позволяющий просматривать отчеты Team Build и информацию о выполнении сборки в Team Explorer.
• Веб-служба управления исходным кодом - компонент уровня приложения, используется службой сборки для доступа к исходному коду.
• Веб-служба Team Foundation Build - компонент уровня приложения, принимающий запросы от клиента и координирующий выполнение этапов сборки.
• Служба сборки ( Build Service ) - выполняет различные этапы сборки, получая инструкции от веб-службы Team Build. Ее можно разместить на отдельном сервере сборки или на сервере уровня приложений.
• Хранилище Team Foundation Build - компонент уровня данных, используется для хранения записей, относящихся к процессам Team Build.
• База данных исходного кода - компонент уровня данных для хранения исходного кода, доступ к которому во время выполнения процесса сборки осуществляет служба сборки.

Логика рабочего процесса

Логика процесса сборки Team Build проиллюстрирована на рис.7.11.

увеличить изображение
Рис. 7.1. Логика рабочего процесса Team Build

Подсистема Team Build интегрирована с сервером TFS на уровне приложения и взаимодействует с рабочими элементами, покрытием кода тестами, анализом кода, тестовыми данными и отчетами.

Управление сборкой осуществляется при помощи файла TFSBuild.proj. В нем определяются собираемые проекты, конфигурации, места накопления результатов, анализ кода и выполняемые тесты. Этот файл генерируется мастером Team Build Creation Wizard при создании сборки. Его можно редактировать непосредственно.

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

Важные аспекты

Обратите внимание следующие ключевые моменты физической архитектуры Team Build:

• Team Foundation Build работает на основе MSBuild.
• Файл TFSBuild.proj содержит все параметры сборки. Он создается мастером Team Build Creation Wizard и допускает непосредственное редактирование.
• В файле TFSBuild.rsp содержатся параметры командной строки для MSBuild. Его также можно изменять.
• Собственные этапы сборки и уведомления создаются посредством событий BuildStatusChangeEvent и BuildCompletionEvent.
• TeamBuild интегрируется с рабочими элементами, охватом кода, анализом кода и тестовыми данными.

Принципы работы Team Build

Team Build состоит из службы Team Build Service, работающей поверх системы сборки MSBuild. Система MSBuild выполняет собственно сборку, а служба Team Build отвечает за взаимодействие с уровнем приложения TFS. Сборки Team Build создаются в клиенте Visual Studio. Разработчик может запускать их из клиента, при помощи события на сервере сборки или из командной строки, например, как запланированную задачу. Процесс сборки состоит из следующих этапов:

1. Получение исходного кода из системы управления исходным кодом и его помещение в каталог сборки.
2. Компиляция исходного кода и создание двоичных файлов.
3. Выполнение анализа кода (необязательный этап).
4. Создание рабочего элемента, если произошел сбой сборки.
5. Выполнение тестов (необязательный этап).
6. Оценка покрытия кода тестами (необязательный этап).
7. Запись сведений о сборке.
8. Копирование сборки в место накопления.

После завершения сборки вам доступны следующие элементы:

• Сведения о сборке Просмотреть их можно из любого клиента или в отчетах.
• Двоичные файлы сборки Находятся в месте накопления.
• Журнал сборки Содержит сведения об ошибках и предупреждения.
• Рабочий элемент Если во время сборки произошел сбой, создается рабочий элемент, позволяющий отследить, где он возник.