четверг, 9 декабря 2010 г.

Основы непрерывной интеграции с помощью Team Foundation Server 2010

Team Foundation Server – это гораздо больше, чем просто сервер непрерывной интеграции. Он включает в себя систему контроля версий, управление задачами, интегрируется с SQL Server для предоставления отчетов. Это комплексное решение для организации коллективной разработки ПО.

В этой статье мы коснемся непрерывной интеграции в Team Foundation Server 2010.

Конфигурирование TFS Build

Пользователи TFS 2010 используют билд-контроллеры для управления задачами построения сборок ПО. Вы можете установить его на один сервер или распределить процесс сборки между несколькими серверами. Пул агентов сборки – набор из одного или нескольких агентов сборки. Агенты сборки – это сервисы, которые могут быть установлены на той же или отдельной машине для распределения задач сборки.

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

До того, как вы добавите билд для сборки в очередь билдов, вы должны определить ее (рис.1).

image

Рис.1

В случае если вы еще не добавили билд-сервис, билд-контроллеры и агенты – это нужно сделать в разделе Build Configuration в TFS Administration Console (подробная информация по настройке есть в MSDN, например тут http://msdn.microsoft.com/ru-ru/library/dd793166.aspx).

Вы можете создавать сборки непрерывной интеграции (при CheckIn в репозиторий), запланированные сборки и т.д.

После того, как вы дали имя вашему новому определению сборки, выбираем ее тип (рис. 2):

image

Рис.2

Возможные типы:

  • Manual (ручная) – фактически это не триггер. Он говорит TFS ничего не делать до того, пока мы не поставим билд в очередь вручную.
  • Continuous Integration (непрерывная интеграция) – триггер следует строгим принципам непрерывной интеграции, и делает билд после каждого Check-In.
  • Rolling builds (повторяющийся билд) – эффективен, если разработчики в вашей команде делают check-in быстрее, чем процесс сборки. Таким образом Check-in будут накапливаться и строиться не чаще, чем через определенное время.
  • Gated Check-in (гейт) – защищает репозиторий от попадания в него плохого кода. Компилирует код и запускает модульные тесты до check-in. Если обраруживаются проблемы – check-in не происходит.
  • Sсhedule (график) – самый простой триггер, который организует ваши билды по расписанию, например ночные или билды по выходным.

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

На вкладке Build Defaults выберите билд-контроллер, который будет использоваться для построения и выходную папку, куда билд-агент будет копировать результаты сборки и лог-файл (рис.3). Это может быть например сетевое хранилище, конечно при условии, что у вас достаточно прав на использование его.

image

Рис.3

Давайте теперь посмотрим на вкладку Process (рис.4). Определения процесса сборки (Build Definition) в TFS 2010 хранятся в файлах XAML и Windows Workflow Foundation.

image

Рис.4

Если вы используете шаблон по умолчанию (Default Template), вы должны выбрать элементы, для которых будет происходить построение из репозитория системы контроля версий. Это например может быть файл решения. Так же это может быть скрипт MSBuild.

Выберем файл решения для построения. Переходим на последнюю вкладку сохранения информации о билде (Build Retention). Тут мы можем определить, сколько времени хранить информацию о билдах (рис. 5).

image

Рис.5 

Все готово. Теперь каждый день в 13:20 будет выполняться билд (обеденное время), и прийдя с обеда можно исправить ошибки сборки. Для моего проекта билд при каждом Check-In кажется избыточным, тестерам нужно еще протестировать результат сборки.

Проверить как все работает можно, сделав сборку вручную. Для этого можно в Team Explorer попросить собрать новый билд в контекстном меню вашей конфигурации сборки (рис 6, рис.7).

image

Рис.6

image

Рис.7

В этой статье я не рассмотрел процесс конфигурирования MSBuild и множество других тонкостей. Мне хотелось бы, чтобы она послужила стартом к работе с TFS 2010 в плане обеспечения непрерывной интеграции.

Более подробно можно будет почитать в книжке: Continuous Integration in .NET

4 комментария: