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

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

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

1. Выясните, кто будет пользоваться сборкой.
2. Просмотрите сценарии решения.
3. Выявите распространенные затруднения.

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

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

• команды разработчиков;
• команды тестировщиков;
• внутренние контролеры;
• внешние контролеры бета-версии;
• заказчики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Разработка проекта с внешними зависимостями Если вы включаете внешние зависимости посредством ветвления, используйте ссылки проекта, чтобы сборка работала на сервере сборки без каких-либо дополнительных действий. Если для ссылок на внешние зависимости используется сопоставление рабочей области на клиентской стороне, сопоставление необходимо поддерживать на сервере сборки, чтобы она выполнялась успешно. Подробнее - в лекции 6.
• Разработка проекта установки По умолчанию Team Build не поддерживает проекты установки. Для компиляции проекта установки и копирования двоичных файлов в место накопления используйте собственный послесборочный этап. Более подробную информацию вы найдете в статье по адресу http://msdn2.microsoft.com/en-us/library/ms404859(VS.80). aspx. и Разработка приложений .NET 1.1 По умолчанию Team Build не поддерживает приложения .NET 1.1. Сборки .NET 1.1 поддерживаются комплектом MSBuild Extras Toolkit for .NET 1.1 (MSBee), но при этом необходимо обновить проекты и решения до Visual Studio 2005. Если обновить проекты и решения нельзя, используйте для компиляции приложений .NET 1.1 собственный послесборочный этап. Скачать MSBee можно по адресу http://www. codeplex.com/MSBee. Подробнее о создании собственного этапа сборки для компиляции приложений .NET 1.1 - в блоге по адресу http://blogs.msdn. com/nagarajp/archive/2005/10/26/485368.aspx или в статье "Microsoft SDC DevEnv task" по адресу http://www.codeplex.com/sdctasks.
• Разработка приложений 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, выполнив следующие действия:

1. Извлеките файл из системы управления исходным кодом.
2. Обновите информацию в файле.
3. Верните файл в систему управления исходным кодом.

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

Резюме

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

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

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

• Дополнительные сведения вы найдете в разделах "Как автоматически выполнять анализ кода при помощи Team Build ", "Как настроить непрерывную сборку в Visual Studio Team Foundation Server ", "Как настроить плановую сборку в Visual Studio Team Foundation Server ".
• Дополнительную информацию о Team Build вы найдете по адресу http:// msdn2.microsoft.com/en-us/library/ms181710(vs.80).aspx.