Team Build в Team Foundation Server (TFS) - Архитектура

Written on . Posted in Разработка и тестирование

ОГЛАВЛЕНИЕ

Страница 2 из 5

Архитектура

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

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

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

  • Мастер создания нового типа сценария сборки – Этот доступный из Team Explorer компонент на стороне клиента обеспечивает возможность создания новых типов сценариев сборок.
  • Окно просмотра Team Build – Этот доступный из Team Explorer компонент на стороне клиента обеспечивает возможность просмотра в Team Explorer сообщения Team Build и информации о процессе сборки.
  • Веб-сервис системы контроля версий – Этот компонент уровня приложений используется сервисом сборки для доступа к исходному коду.
  • Веб-сервис сборки Team Foundation – Этот компонент уровня приложений принимает запросы от клиента и управляет выполнением этапов сборки.
  • Сервис сборки – Этот сервис выполняет этапы сборки в ответ на инструкции, получаемые от Веб-сервиса Team Build. Сервис сборки можно разместить на отдельном сервере сборки или на сервере уровня приложений.
  • Хранилище сборок Team Foundation – Этот компонент уровня данных используется для хранения записей, относящихся к процессам Team Build.
  • База данных исходного кода – Этот компонент уровня данных используется для хранения исходного кода, к которому обращается сервис сборки во время сборки.

Логическая последовательность операций

На рис. 7.1 показана логическая последовательность операций Team Build.


Рис. 7.1 Логическая последовательность операций Team Build

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

Файл TFSBuild.proj управляет процессом сборки, включая выбор проектов, участвующих в сборке, выбор конфигураций, мест публикации результатов сборки, анализ кода и выбор тестов, которые должны быть проведены. Этот файл формируется Team Build Type Creation Wizard (Мастер создания нового типа сценария сборки) при первом создании сборки и может редактироваться напрямую.

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

Ключевые моменты

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

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

Как работает Team Build

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

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

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

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

форум программирование