СМ-Консалт
 

Глава 8

Статьи Технологии Microsoft: .NET, Visual Studio Team System Коллективная разработка с использованием Visual Studio Team Foundation Server Часть III - Сборки

Глава 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 .

26.12.2008

Комментарии

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Бесплатный вебинар 14 декабря в 14 00 по Мск - «Секреты управления ИТ-командой: 10 важных практик, которые сделают команду эффективной»

Новые статьи в библиотеке

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Отчет, презентация и видео доклада для Октябрьской встречи Петербургского клуба менеджеров проектов в IT - SPM Meetup #36

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2016.
Карта сайта