Материал: ВВПИ. Лекции

Лекция 14. VSTS: конфигурационное управление

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

•интеграция с системой управления элементами работы (а через нее и с системой отчетов) позволяют эффективнее отслеживать процесс разработки и управлять им;

•интеграция с интегрированной средой разработки является стандартом для любой системы контроля версий, однако для систем управления сборок это не так – благодаря удобному пользовательскому интерфейсу интегрированному в единую среду разработки управление сборками осуществляется значительно проще.

Система контроля версий

Функциональность ею предоставляемая в большинстве своем является стандартной, поэтому более подробно мы остановимся на следующих ее особенностях:

•отслеживание изменений отдельных файлов и их «провязка» с элементами работы;

•правила внесения изменений (check-in policies);

•средства управления «ветками»;

•сохранение изменений без внесения.

Отслеживание изменений отдельных файлов. Основным отличительным свойством системы контроля версий в TFS является интеграция его с другими подсистемами TFS, а также более тесная интеграция с Visual Studio, чем во многих других системах контроля версий. Большая часть этих возможностей наглядно демонстрируется самим внешнем вида check-in диалога, представленным на рис. 13.1.

102

Рис. 13.1. Check-in диалог.

На первый взгляд диалог выгляди достаточно стандартно – список файлов и поля для внесения комментариев к вносимым файлам. Однако в глаза бросается панель с дополнительными закладками в левой части окна. Именно эта панель и позволяет получить доступ к специфической функциональности.

Наиболее востребованной является поддержка в TFS возможности связи вносимых изменений с элементами работы, которую можно выполнить на закладке Work Items, показанной на рис. 13.2.

103

Рис. 13.2. Закладка Work Items.

Разработчик, который вносит изменения в файлы с исходными текстами, может найти соответствующие этим изменениям элементы работы (ведь он либо исправлял какую-нибудь ошибку, либо выполнял задачу и т.п.), используя любой из доступных запросов, а также текстовый поиск. Запрос задается в секции Query – см. рис. 13.2. Результат его выполнения отобразится в главном окне диалога на этом рисунке. Для того, чтобы связать конкретный элемент работы из этого запросы с данным изменением исходников, надо выбрать галочку в первом столбце. На рис. 13.2 она выбрана для последнего элемента в списке – элемента работы Task 107. Далее, бывает так, что это изменение исходников «закрывает» данный элемент работ. Тогда в столбце Check-in Action нужно выбрать действие Resolve – это действие, на равнее с другими, определяется в шаблоне процесса для всех элементов работы данного типа. Если же данное изменение не «закрывает» данный элемент работы, то в этом столбце нужно проставить действие Associate, и оно просто установит связь этого изменения с данным элементом работы.

104

Рис. 13.3. Закладка Check-in Notes.

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

105