VSTS: конфигурационное управление
Создание проекта MsBuild. Проект MsBuild, не смотря ни на что, все-таки составляет основу системы автоматических сборок TFS. Однако специалистами Майкрософт потрачено немало усилий на то, чтобы мы могли забыть о необходимости поддерживать большие и сложные XML-файлы с описанием сборок. В TFS для создания проектов MsBuild реализован достаточно удобный мастер ( рис. 14.25 – 14.27).
На первом шаге ( рис. 14.25) мы выбираем в системе контроля версий те решения, которые должны собираться в данной сборке.
На втором шаге (см. рис. 14.26) мы выбираем те конфигурации в этих решениях, которые нужно собирать.
И, наконец, на третьем шаге ( рис. 14.27) мы выбираем те тесты, которые мы хотим запустить и отмечаем, хотим ли мы проводить статический анализ кода. В отличии от TFS 2005, где при выборе тестов можно было использовать только заранее подготовленные тестовые пакеты, в TFS 2008 появилась такая востребованная возможность как автоматическое подключение пакетов тестов по метке имени (обычно сборки начинающиеся или заканчивающиеся на Test). Эта возможность позволяет без дополнительных затрат включить выполнение модульных тестов в автоматическую сборку.
Создание сборочного агента. Появление сборочных агентов в TFS 2008 позволило значительно расширить возможности конфигурации автоматического выполнения процесса сборки. Сборочный агент – это процесс, запущенный на некоторой выделенной машине, в рамках которого и происходит автоматическая сборка. На самом деле, сборочные агенты выполняются процессом TFSBuild, запущенным в виде сервера или консольного приложения1Последнее важно если в сборке используются автоматические тесты на пользовательский интерфейс – сервис не может его выполнить. Для сборок с такими тестами необходим интерактивный процесс. .
Одна машина может размещать у себя несколько процессов TFSBuild, каждый из которых доступен как Web-сервис на определенном порту. При этом каждый процесс TFSBuild может содержать несколько сборочных агентов, которые отличаются именами и рабочими папками, в которых они выполняют сборку.
Несмотря на сложность описанного процесса, настройка его достаточно проста и производится, в основном, с помощью окна свойств агента (см. рис. 14.28).
Запуск процесса сборки и анализ результатов. Итак, после того как описание сборки создано и инфраструктура выполнения настроена, мы можем запустить процесс сборки с помощью команды Queue New Build, вызывающей окно, показанное на рис. 14.29.
При запуске новой сборки пользователь может выбрать описание сборки, сборочного агента (по умолчанию используется агент, заданный в описании), папку для хранения результатов (так же берется по умолчанию из описания), приоритет и позицию в очереди (каждый сборочный агент может выполнять не более одной сборки за раз), а также дополнительные параметры командной строки для MsBuild. Как правило, в приведенном окне можно использовать все настройки по умолчанию, менять которые приходится только в особых случаях.
После того, как сборка помещена в очередь, она отображается в списке сборок ( рис. 14.30), откуда можно перейти к окну с детальной информацией о сборке ( рис. 14.31). В этом окне отображается ход сборки, или её результаты, если она завершена.
Пример на рис. 14.31 наглядно демонстрирует средства Team Explorer по визуализации результатов. В открытом окне виден список не прошедших тестов, а также имеются ссылки на все файлы с логами, которые можно открыть одним щелчком в окружении студии (при условии, что у вас есть доступ к сетевой папке, куда они были скопированы). Кроме того, в информации о прошедшем процессе сборке можно увидеть, какие изменения исходных текстов программ в нее попали, а также то, какими элементами работы они были обусловлены.
Управление процессом сборки. Все продемонстрированные нами средства визуального описания сборок доступны не только при создании такого описания, но и для любого из существующих описаний сборок (команда Edit Build Definition ). Единственным исключением является файл MsBuild, который, будучи однажды сгенерирован с помощью мастера, далее поддерживается вручную.
Этот файл можно найти в системе контроля версий ( рис. 14.32) в той папке, которая была выбрана при его создании. Эта папка содержит два файла:
- PROJ-файл – основной файл, описывающий задачи MsBuild. Этот файл содержит достаточное количество сгенерированных комментариев, позволяющих производить простую настройку (добавить или удалить решение, включить или отключить статический анализ и т.д.) достаточно легко, однако для более сложных изменений необходимо знакомство как с принципами работы MsBuild, так и со спецификой MsBuild-задач, используемых в TFS.
- RSP-файл, который содержит параметры командной строки для передачи при запуске MsBuild.
Заметим, что для большинства простых проектов обычно хватает настроек, доступных через визуальные редакторы, и изменять эти файлы приходится относительно редко.