Знакомство с Team Build

Показывать лекцию целиком

Обзор

В этой лекции объясняется, как автоматизировать процесс сборки при помощи 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. Разработчик может запускать их из клиента, при помощи события на сервере сборки или из командной строки, например, как запланированную задачу. Процесс сборки состоит из следующих этапов:

Получение исходного кода из системы управления исходным кодом и его помещение в каталог сборки.

Компиляция исходного кода и создание двоичных файлов.

Выполнение анализа кода (необязательный этап).

Создание рабочего элемента, если произошел сбой сборки.

Выполнение тестов (необязательный этап).

Оценка покрытия кода тестами (необязательный этап).

Запись сведений о сборке.

Копирование сборки в место накопления.

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

Сведения о сборке Просмотреть их можно из любого клиента или в отчетах.

Двоичные файлы сборки Находятся в месте накопления.

Журнал сборки Содержит сведения об ошибках и предупреждения.

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

Как определить стратегию сборки

Для определения стратегии сборки выполните следующие действия:

Выясните, кто будет пользоваться сборкой.

Просмотрите сценарии решения.

Выявите распространенные затруднения.

Определение потребителей сборки

Большинство команд разработчиков создают сборки для одного или нескольких типов потребителей:

команды разработчиков;

команды тестировщиков;

внутренние контролеры;

внешние контролеры бета-версии;

заказчики.

У потребителей каждого типа свои требования к качеству сборок и частоте их выпуска. Как правило, их можно разделить на две группы: одним нужны плановые сборки, выпускаемые по расписанию, другим - сборки, оперативно создаваемые на основе происходящих событий. Плановые сборки обычно создаются ежедневно, но это может происходить как чаще, так и реже. Сборки, управляемые событиями, обычно инициируются возвратом исходного кода в систему и предназначены для быстрого предоставления команде разработчиков информации о качестве кода. Если у разработчиков возникли проблемы с неработающими сборками, попробуйте использовать модель возврата кода с контролем качества ( gated check-in ), в которой сборки тестируются, прежде чем разрешается их помещение в дерево исходного кода.

Сценарии сборки

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

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

Ежедневная сборка и непрерывная интеграция В некоторых командах для оперативного предоставления разработчикам информации о качестве кода используются сборки с непрерывной интеграцией - при каждом возврате исходного кода. Система непрерывной интеграции в чистом виде вполне подходит для небольших команд разработчиков, а вот крупные команды с частым возвратом исходного кода и продолжительной сборкой рискуют перегрузить сервер сборки. Если это случилось, попробуйте использовать скользящую сборку ( rolling build ). Сборки при этом создаются не так часто, но и время между возвратом кода и получением результата возрастает незначительно.

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

Плановые сборки

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

Чаще всего потребителями плановых сборок являются:

тестировщики;

внутренние контролеры сборки;

внешние контролеры.

Для создания плановой сборки выполните следующие действия:

Создайте пакетный файл для выполнения сборки из командной строки.

Используйте планировщик Windows для выполнения пакетного файла по расписанию.

Более подробную информацию вы найдете в лекции 9.

Непрерывная интеграция

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

Выберите одну из следующих стратегий в зависимости от размера команды, размера сборки и частоты возврата кода:

Сборка сразу после возврата кода.

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

Более подробную информацию вы найдете в лекции 8.

Возврат кода с контролем качества

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

Типичные проблемы

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

Разработка проекта с внешними зависимостями Если вы включаете внешние зависимости посредством ветвления, используйте ссылки проекта, чтобы сборка работала на сервере сборки без каких-либо дополнительных действий. Если для ссылок на внешние зависимости используется сопоставление рабочей области на клиентской стороне, сопоставление необходимо поддерживать на сервере сборки, чтобы она выполнялась успешно. Подробнее - в лекции 6.

Разработка приложений Microsoft Visual Basic® 6.0 По умолчанию Team Build не поддерживает приложения Visual Basic 6.0. Для компиляции таких приложений используйте собственный послесборочный этап.

Подробнее - в статье "MSBuild task to build VB6" по адресу http:// freetodev.spaces.live.com/blog/cns!EC3C8F2028D842D5!261.entry.

Особенности крупных проектов

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

требуют более сложной структуры ветвления и слияния;

часто требуют управления зависимостями между разными решениями и командными проектами;

чаще возникает необходимость поддерживать несколько сборок для компонентов и команд разработчиков.

Работая в крупных командах разработчиков, учитывайте следующие соображения:

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

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

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

Настройка сборки

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

Извлеките файл из системы управления исходным кодом.

Обновите информацию в файле.

Верните файл в систему управления исходным кодом.

При следующем выполнении сборки будут использованы обновленные данные. Подробнее о настройке сборки - в разделах "Настройка" руководства по сборке и практических рекомендациях по сборке в этом курсе.

Резюме

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

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

Дополнительные ресурсы

Дополнительные сведения вы найдете в разделах "Как автоматически выполнять анализ кода при помощи Team Build ", "Как настроить непрерывную сборку в Visual Studio Team Foundation Server ", "Как настроить плановую сборку в Visual Studio Team Foundation Server ".

Дополнительную информацию о .

Занятие пройдено

Предыдущее занятие Занятие пройдено Следующее занятие

Вернуться к учебному плану