Team Build в Team Foundation Server (TFS) - Как выбрать стратегию сборки

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

ОГЛАВЛЕНИЕ

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

Как выбрать стратегию сборки

При выборе стратегии сборки руководствуйтесь следующей схемой:

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

Для кого создается сборка

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

  • Группа разработки
  • Группа тестирования
  • Внутренние потребители сборок
  • Внешние потребители сборок
  • Заказчики

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

Обзор сценариев решения

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

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

Рассмотрим самые распространенные сценарии Team Build:

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

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

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

  • Группа тестирования.
  • Внутренние потребители сборки.
  • Внешние потребители.

Создание плановой сборки происходит в два этапа:

  1. Создание командного файла с командной строкой сборки.
  2. Командный файл выполняется по графику с помощью Windows Scheduled Tasks (Планировщик задач Windows).

Сборка в результате непрерывной интеграции

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

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

  1. Сборка в результате непрерывной интеграции сразу после формирования события регистрации изменений.
  2. Скользящая сборка после заданного числа событий регистрации изменений или через заданный промежуток времени (в зависимости от того, какое условие выполняется первым).

Регистрация изменений с порогом качества

Регистрация изменений с порогом качества – это процесс проверки каждого изменения на соответствие некоторому стандарту качества перед добавлением его в дерево исходного кода. Назначение регистрации изменений с порогом качества – сокращение числа сбоев при сборке и повышение качества сборки. Это достигается путем обязательного тестирования каждого изменения перед его приемом.

Наиболее часто встречающиеся препятствия

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

  • Сборка проекта с внешними зависимостями. Если для установления внешних зависимостей в групповом проекте используется ветвление, можно использовать ссылки на проекты, и сборка будет выполняться на сервере сборки без каких-либо дополнительных шагов. Если внешние зависимости реализованы через отображение рабочего пространства на стороне клиента, для успешной сборки необходимо обслуживать отображение на сервере сборки. Более подробно об этом рассказывается в Главе 6 «Управление зависимостями системы контроля версий в Visual Studio Team System».
  • Сборка проекта создания пакета установки приложения. Team Build не поддерживает проекты создания пакета установки приложения по умолчанию. Проект создания пакета установки компилируется после сборки, и полученные в результате этого специального этапа двоичные файлы копируются в каталог публикации результатов сборки. Более подробную информацию об этом можно найти в статье «Walkthrough: Configuring Team Foundation Build to Build a Visual Studio Setup Project» (По шагам: Конфигурирование Team Foundation Build для сборки проекта создания пакета установки Visual Studio) по адресу http://msdn2.microsoft.com/en-us/library/ms404859(VS.80).aspx.
  • Сборка приложений .NET 1.1. Team Build не поддерживает приложения .NET 1.1 по умолчанию. Дополнение MSBuild – Комплект инструментов для .NET 1.1 (MSBee) – поддерживает сборки .NET 1.1, но требует, чтобы проекты и решения были обновлены до Visual Studio 2005. Если это невозможно, скомпилировать приложения .NET 1.1 можно в ходе специального этапа после сборки. Скачать MSBee можно по адресу http://www.codeplex.com/MSBee. Более подробно о создании специального этапа сборки для компиляции приложений .NET 1.1 рассказывается в блоге Нагараджу (Nagaraju) (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 по умолчанию. Компиляция приложения Visual Basic 6.0 выполняется в ходе специального этапа после сборки. Примеры компиляции после сборки, которые могут использоваться для компиляции приложений .NET 1.1, ищите в блоге Нагараджу (http://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx) или в статье «MSBuild task to build VB6» (Задача MSBuild для сборки VB6) (http://freetodev.spaces.live.com/blog/cns!EC3C8F2028D842D5!261.entry).

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