Programmnaya_inzheneria

Рис. 13.22. Правила сохранения.

В TFS 2008, в связи с реализацией функциональности по непрерывной интеграции, возникла проблема большого числа описаний сборок и результатов, сохраненных в системе и на диске. Для устранения проблемы был реализован механизм автоматической очистки, получившей название Retention Policy (см. рис 13.22), позволяющий задать, сколько последних результатов нужно хранить. При этом для каждого из типов результат (неудачный, остановленный, частично успешный, успешный) можно задать свое число.

Полезной функцией является то, что политику уничтожения результатов можно отключить для конкретной сборки используя опцию Retain Indefinitely. Результаты, помеченные этой опцией, сохраняются в системе навсегда (или пока опция не будет снята).

121

Рис. 13.23. Выбор агента.

На закладке Build Defaults (см. рис 13.23) мы задаем свойства окружения, которое будет использовано для автоматического запуска процесса сборки. Главным здесь является сборочный агент – процесс, в рамках которого будет выполняться процесс сборки.

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

122

Рис. 13.24. Задание триггера.

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

не запускать процесс сборки автоматически (то есть только «вручную»),

запускать после каждого внесения изменений,

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

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

Создание проекта MsBuild. Проект MsBuild, не смотря ни на что, все-таки составляет основу системы автоматических сборок TFS. Однако специалистами Майкрософт потрачено немало усилий на то, чтобы мы могли забыть о необходимости поддерживать большие и сложные XML-файлы с описанием сборок. В TFS для создания проектов MsBuild реализован достаточно удобный мастер (рис. 13.25 – 13.27).

123

Рис. 13.25. Выбор решений.

На первом шаге (рис. 13.25) мы выбираем в системе контроля версий те решения, которые должны собираться в данной сборке.

124

Рис. 13.26. Выбор конфигураций.

На втором шаге (см. рис 13.26) мы выбираем те конфигурации в этих решениях, которые нужно собирать.

125

Рис. 13.27. Выбор тестов и правил анализа.

И, наконец, на третьем шаге (рис.13.27) мы выбираем те тесты, которые мы хотим запустить и отмечаем, хотим ли мы проводить статический анализ кода. В отличии от TFS 2005, где при выборе тестов можно было использовать только заранее подготовленные тестовые пакеты, в TFS 2008 появилась такая востребованная возможность как автоматическое подключение пакетов тестов по метке имени (обычно сборки начинающиеся или заканчивающиеся на Test). Эта возможность позволяет без дополнительных затрат включить выполнение модульных тестов в автоматическую сборку.

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

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

15 Последнее важно если в сборке используются автоматические тесты на пользовательский интерфейс – сервис не может его выполнить. Для сборок с такими тестами необходим интерактивный процесс.

126

Несмотря на сложность описанного процесса, настройка его достаточно проста и производится, в основном, с помощью окна свойств агента (см. 13.28).

Рис. 13.28. Свойства сборочного агента.

Запуск процесса сборки и анализ результатов. Итак, после того как описание сборки создано и инфраструктура выполнения настроена, мы можем запустить процесс сборки с помощью команды Queue New Build, вызывающей окно, показанное на рис. 13.29.

127

Рис. 13.29. Запуск новой сборки.

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

Рис. 13.30. Список описаний сборок.

После того, как сборка помещена в очередь, она отображается в списке сборок (рис. 13.30), откуда можно перейти к окну с детальной информацией о сборке (рис. 13.31). В этом окне отображается ход сборки, или её результаты, если она завершена.

128

Пример на рис. 13.31 наглядно демонстрирует средства Team Explorer по визуализации результатов. В открытом окне виден список не прошедших тестов, а также имеются ссылки на все файлы с логами, которые можно открыть одним щелчком в окружении студии (при условии, что у вас есть доступ к сетевой папке, куда они были скопированы). Кроме того, в информации о прошедшем процессе сборке можно увидеть, какие изменения исходных текстов программ в нее попали, а также то, какими элементами работы они были обусловлены.

Рис. 13.31. Результаты сборки.

Управление процессом сборки. Все продемонстрированные нами средства визуальной описания сборок доступны не только при создании такого описания, но и для любого из существующих описаний сборок (команда Edit Build Definition). Единственным

129

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

Этот файл можно найти в системе контроля версий (рис. 13.32) в той папке, которая была выбрана при его создании. Эта папка содержит два файла:

PROJ-файл – основной файл, описывающий задачи MsBuild. Этот файл содержит достаточное количество сгенерированных комментариев, позволяющих производить простую настройку (добавить или удалить решение, включить или отключить статический анализ и т.д.) достаточно легко, однако для более сложных изменений необходимо знакомство как с принципами работы MsBuild, так и со спецификой MsBuild-задач, используемых в TFS.

RSP-файл, который содержит параметры командной строки для передачи при запуске MsBuild.

Рис. 13.32. Файл определения проекта.

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

130