Заметки консультанта

Шамрай Александр Владимирович

Глава 8 — Как настроить процесс непрерывной интеграции с помощью Team Build

<< Назад

Область применения

  • Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)
  • Microsoft Visual Studio Team System

Задачи

  • Понять назначение процесса непрерывной интеграции.
  • Настроить процесс непрерывной интеграции, используя Microsoft® Visual Studio® Team System Team Build.
  • Оптимизировать процесс непрерывной интеграции и сократить количество «узких мест» в нем.

Обзор

В данной главе рассматривается, как можно настроить процессы непрерывной интеграции с помощью Team Build и Microsoft Visual Studio Team Foundation Server (TFS). Непрерывная интеграция обеспечивает максимально быструю обратную связь по качеству сборки после регистрации изменений. При коллективной разработке важно получать информацию о качестве изменений как можно раньше, особенно если они в сочетании с коррективами, вносимыми другими разработчиками, нарушают процесс сборки. Непрерывный процесс интеграции дает шанс быстро исправить код, не создавая помех в работе других членов команды и, таким образом, улучшая согласованность и качество сборки.

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

Как использовать данную главу

В этой главе мы изучим стратегии непрерывной интеграции и научимся, используя Team Build, настраивать и конфигурировать процессы сборки, получаемые в процессе непрерывной интеграции. Пошаговый обзор и анализ процесса настройки непрерывной интеграции приведен в разделе «Как: настроить процесс непрерывной интеграции в Visual Studio Team Foundation Server».

Новичкам в TFS и Team Build и тем, кто желает подробнее рассмотреть доступные варианты автоматизации и планирования сборок, рекомендуется прочитать Главу 7 «Team Build».

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

Непрерывная интеграция (Continuous integration, CI) — это процесс создания сборок при каждой регистрации изменений кода в системе контроля версий. Существует несколько различных стратегий сборки в результате непрерывной интеграции:

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

Сборка при каждой регистрации изменений

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

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

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

Более подробно об этом рассказывается в разделе «Как: настроить сборку в процессе непрерывной интеграции в Visual Studio Team Foundation Server».

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

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

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

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

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

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

Определение интервала скользящей сборки

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

Процесс непрерывной интеграции в Team Foundation Server

Team Foundation Server 2005 не обеспечивает стандартного решения для поддержки процесса непрерывной интеграции, но предоставляет разработчику инфраструктуру для реализации собственного решения по организации процесса непрерывной интеграции.

Подробнее о настройке процесса непрерывной интеграции в TFS рассказывается в разделе «Как: настроить процесс непрерывной интеграции в Visual Studio Team Foundation Server». В нем используется решение, предоставленное группой разработки Visual Studio Team System. Это решение устанавливает Веб-сервис, который выполняется под учетной записью, имеющей доступ к серверу TFS. Team Foundation Server при возникновении определенных событий может посылать сообщение электронной почты или вызывать Веб-сервис. Механизм событий используется данным решением для подписки Веб-сервиса на CheckinEvent (Событие регистрации изменений). Тогда каждый раз при регистрации изменений Веб-сервис будет запускать Team Build.

Примечание: Пользователи TFS 2008 могут планировать сборки из Visual Studio. Для этого щелкаем правой кнопкой мыши на описании типа сценария сборки под узлом Builds в Team Explorer, выбираем Edit Build Definition, щелкаем Trigger и активируем сборку при регистрации изменений.

Заключение

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

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

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

Дополнительные источники

  • Более подробно об использовании решения организации процесса непрерывной интеграции Visual Studio Team System рассказывает статья «Continuous Integration Using Team Foundation Build» (Непрерывная интеграция с использованием Team Foundation Build) (http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx ).
  • Скачать пакет установки MSI решения по организации процесса непрерывной интеграции Visual Studio Team System можно по адресу http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi .
  • Более подробно о гибкой разработке и непрерывной интеграции в Team Foundation Server смотрите в статье «Extend Team Foundation Server To Enable Continuous Integration» (Расширение Team Foundation Server для обеспечения процесса непрерывной интеграции) по адресу http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx .

<< Назад

 
%d такие блоггеры, как: