СМ-Консалт
 

Глава 7

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

Глава 7 - Team Build  

Содержание

 

Полезные материалы в тему статьи:

 

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

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

Задачи

  • Понять архитектуру Microsoft® Visual Studio® Team System Team Build.
  • Изучить компоненты, составляющие Team Build.
  • Понять функциональные возможности, предоставляемые Team Build.
  • Правильно выбрать стратегию сборки.
  • Определить, каким образом может понадобиться изменить стратегию выполнения сборки при работе над большим проектом

Обзор

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

Team Build создан на базе Microsoft Build Engine (MSBuild) и может быть использован для извлечения необходимого для сборки исходного кода, компиляции решений и, если требуется, выполнения модульного тестирования и статического анализа кода как части процесса сборки. Также результат сборки может быть опубликован в заданный совместно используемый каталог.

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

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

Данная глава рассказывает о функциональности, предоставляемой Team Build для автоматизации и управления процессом сборки. Она научит понимать разные стратегии планирования сборки. Чтобы извлечь максимальную пользу из этой главы, следует:

Архитектура

В данном разделе представлена архитектура Team Build через описание его физической архитектуры и логической последовательности операций.

Физическая архитектура

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

  • Мастер создания нового типа сценария сборки - Этот доступный из Team Explorer компонент на стороне клиента обеспечивает возможность создания новых типов сценариев сборок.
  • Окно просмотра Team Build - Этот доступный из Team Explorer компонент на стороне клиента обеспечивает возможность просмотра в Team Explorer сообщения Team Build и информации о процессе сборки.
  • Веб-сервис системы контроля версий - Этот компонент уровня приложений используется сервисом сборки для доступа к исходному коду.
  • Веб-сервис сборки Team Foundation - Этот компонент уровня приложений принимает запросы от клиента и управляет выполнением этапов сборки.
  • Сервис сборки - Этот сервис выполняет этапы сборки в ответ на инструкции, получаемые от Веб-сервиса Team Build. Сервис сборки можно разместить на отдельном сервере сборки или на сервере уровня приложений.
  • Хранилище сборок Team Foundation - Этот компонент уровня данных используется для хранения записей, относящихся к процессам Team Build.
  • База данных исходного кода - Этот компонент уровня данных используется для хранения исходного кода, к которому обращается сервис сборки во время сборки.

Логическая последовательность операций

На рис. 7.1 показана логическая последовательность операций Team Build.

 

 

Рис. 7.1 Логическая последовательность операций Team Build

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

Файл TFSBuild.proj управляет процессом сборки, включая выбор проектов, участвующих в сборке, выбор конфигураций, мест публикации результатов сборки, анализ кода и выбор тестов, которые должны быть проведены. Этот файл формируется Team Build Type Creation Wizard (Мастер создания нового типа сценария сборки) при первом создании сборки и может редактироваться напрямую.

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

Ключевые моменты

При работе с Team Build необходимо помнить следующие ключевые моменты его физической архитектуры:

  • Team Foundation Build является надстройкой над MSBuild.
  • Файл TFSBuild.proj содержит все настройки сборки. Он создается с помощью мастера Team Build Type Creation Wizard. После создания файл можно редактировать напрямую.
  • Файл TFSBuild.rsp содержит параметры командной строки для MSBuild. Изменяя этот файл, можно осуществлять более тонкую настройку процесса сборки.
  • Система уведомлений о событиях посредством событий BuildStatusChangeEvent (Событие изменения статуса сборки) и BuildCompletionEvent (Событие завершения сборки) делает возможной реализацию специальных этапов процесса сборки или формирование уведомлений.
  • Team Build интегрируется с рабочими элементами, инструментарием анализа покрытия кода тестами и статического анализа кода и сценариями тестирования.

Как работает Team Build

Team Build состоит из Сервиса Team Build, работающего поверх системы сборки MSBuild. MSBuild отвечает за сам процесс сборки, тогда как Сервис Team Build обеспечивает обмен информацией с уровнем приложений TFS. Типы сценариев сборки создаются из клиента Visual Studio, и запускать их можно с клиентского компьютера по событию сервера сборки или из командной строки, например, как плановую задачу. Запущенный процесс сборки включает следующие этапы:

  1. Получение исходных файлов из системы контроля версий в каталог сборки.
  2. Компиляция исходного кода и получение двоичных файлов.
  3. Анализ кода (необязательный).
  4. Создание рабочего элемента в случае сбоя процесса сборки.
  5. Тестирование (необязательный).
  6. Оценка покрытия кода тестами (необязательный).
  7. Протоколирование деталей процесса сборки.
  8. Копирование сборки в место публикации результатов сборки.

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

  • Детали сборки. Детали сборки можно получить с любого клиента или из отчетов.
  • Двоичные файлы сборки. Двоичные файлы размещаются в месте публикации результатов сборки.
  • Журнал регистрации сборки. В журнале регистрации можно найти ошибки и предупреждения.
  • Рабочий элемент. Если сборка завершается сбоем, создается рабочий элемент, по которому можно отследить сбой сборки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более подробно об этом рассказывается в Главе 9 , «Как настроить плановые сборки с помощью Team Build» .

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

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

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

Более подробно об этом рассказывается в Главе 8, «Как настроить процесс непрерывной интеграции с помощью Team Build» .

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

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

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

Существует несколько часто встречающихся сценариев, которые по умолчанию не поддерживаются в полной мере 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/nagaraip/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/nagaraip/archive/2005/10/26/485368.aspx ) или в статье «MSBuild task to build VB6» (Задача MSBuild для сборки VB6) (http://freetodev.spaces.live.com/blog/cnslEC3C8F2028D842D51261.entrv ).

Рекомендации по работе над большим проектом

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

  • Им нужна более сложная структура ветвления и слияния.
  • Для них более высока вероятность работы с зависимостями между решениями и групповыми проектами.
  • Для них более высока вероятность работы с несколькими сценариями сборки для компонентов и групп.

При работе с большими группами разработки необходимо помнить следующее:

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

Настройка сборки

Редактируя файл TFSBuild.proj, можно изменять информацию о сборке, такую как сервер сборки, место размещения результатов сборки или каталог сборки.

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

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

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

Более подробную информацию о настройке процесса сборки можно найти в разделе «Настройка» частей «Рекомендации по выполнению процесса сборки» и «Практики сборки» данного руководства.

Заключение

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

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

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

 

26.12.2008

Комментарии

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

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

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

Вышла версия BIPULSE 6.2

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

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

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

Мифы про ГОСТ 34

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

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

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

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

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

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

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

Дружите с нами на 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-2017.
Карта сайта