7.1. Физическая архитектура и логика рабочего процесса Team Build

Team Build – инструментальное средство командной работы со сбороками приложений.

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

• Мастер 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.1.

Рис. 7.1. Логика рабочего процесса Team Build

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

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

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

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

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

- на уровне клиента (вручную);

- при помощи события на сервере сборки (как запланированную задачу);

- из командной строки (как запланированную задачу).

Процесс сборки состоит из следующих этапов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• заказчики.

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

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

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

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

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

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

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

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

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

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

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

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

7.4. Типичные проблемы при работе с Team Build

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

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

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

• Разработка приложений .NET 1.1, либо проектов в старых версиях VS. По умолчанию Team Build не поддерживает приложения .NET 1.1 и старые версии VS. Сборки .NET 1.1 поддерживаются комплектом MSBuild Extras Toolkit for .NET 1.1 (MSBee), но при этом необходимо обновить проекты и решения до Visual Studio 2005. Если обновить проекты и решения нельзя, используйте для компиляции приложений .NET 1.1собственный послесборочный этап.

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

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

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

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

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

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

С точки зрения крупных команд разработчиков имеют значение такие особенности:

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

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

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

7.5. Настройка плановой сборки

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

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

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

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

Выбор частоты плановой сборки

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

Ежечасные сборки

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

Ежедневные сборки

Это наиболее распространенная частота сборки. При этом разработчики каждое утро получают готовую к тестированию сборку со всеми вчерашними изменениями.

Еженедельные сборки

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

7.6. Настройка непрерывной интеграции

Непрерывная интеграция (continuous integration) - процесс создания сборок при каждом возврате кода в систему управления исходным кодом.

Перечислим различные стратегии непрерывной интеграции:

1. Сборка при каждом возврате

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

• время выполнения командной сборки;

• среднее время между возвратами кода;

• интервал времени, в котором возвраты осуществляются особенно часто.

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

2. Сборка после определенного числа возвратов

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

3. Сборка по истечении определенного промежутка времени

Создание сборок через определенные промежутки времени после возврата - более совершенный способ. Он позволяет гарантированно получить сборку с небольшой задержкой относительно последнего возврата. При этом с каждой сборкой может быть связано разное число возвратов - от одного до нескольких. Чем больше возвратов, тем сложнее определить, который из них вызвал сбой.

4. Сборка по обоим условиям

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

Для определения оптимального интервала выполнения сборки нужно разделить среднее время между возвратами на длительность процесса сборки. Допустим, сборка занимает 10 минут, а среднее время между возвратами - 5 минут. Установите выполнение сборки после двух возвратов и таймаут 10 минут. При этом сборка в любом случае завершится к тому времени, когда будет инициирована следующая сборка. Если сервер все равно чрезмерно перегружается, эти значения можно увеличить.

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

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

Для настройки непрерывной интеграции в TFS используется решение, предоставленное командой разработчиков Visual Studio Team System. Оно устанавливает веб-службу, работающую от имени учетной записи, имеющей доступ к серверу TFS. Сервер TFS способен отправлять сообщения электронной почты или вызывать веб-службу при наступлении определенного события. Предлагаемое решение непрерывной интеграции использует механизм событий для связывания веб-службы с событием Checkin Event. В результате каждый раз, когда происходит возврат, веб-служба инициирует выполнение сборки.