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

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

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

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

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

• отслеживание изменений отдельных файлов и их "провязка" с элементами работы;
• правила внесения изменений (check-in policies);
• средства управления "ветками";
• сохранение изменений без внесения.

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

увеличить изображение
Рис. 14.1. Check-in диалог

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

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

увеличить изображение
Рис. 14.2. Закладка Work Items

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

увеличить изображение
Рис. 14.3. Закладка Check-in Notes

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

увеличить изображение
Рис. 14.4. Закладка Policy Warnings

Интересным нововведение TFS как системы контроля версий является гибкая система задания правил внесения изменений (check-in policies), о которой будет подробнее рассказано позже. На закладке Policy Warnings ( рис. 14.4) разработчику показывается список правил, с которыми вошло в конфликт его изменение (или процедура внесения изменений).

увеличить изображение
Рис. 14.5. Свойства набора изменений

Большинство свойств пакета изменений можно изменить в дальнейшем в окне редактирования пакета изменений ( рис. 14.5). Единственное свойство, которое нельзя изменить из этого окна – ассоциации с элементами работы. Для установки ассоциаций элемента работы и пакета изменений необходимо обратится к редактору элемента работы.

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

Правила задаются с помощью специального вида .NET сборок, реализующих определенные интерфейсы. Несколько правил поставляется вместе с самим TFS, огромное количество правил реализовано сообществом разработчиков и находится в открытом доступе. Если же найти идеально подходящее правило так и не удалось, в Интернет можно найти огромное количество информации о написании собственных правил.

В стандартную поставку TFS входят следующие правила:

• Work Items – предполагает, что каждый пакет изменений кроме файлов должен иметь ассоциацию с элементом работы;
• Builds – проверяет, что перед внесением изменений разработчик убедился в собираемости проекта;
• Testing – проверяет, что перед внесением изменений разработчиком были исполнены тесты. К сожалению, правило не может определить какие именно тесты надо запускать для проверки данного изменения, поэтому данное правило не всегда эффективно;
• Code Analysis – выполняет статический анализ кода перед внесением изменений.

В пакете Team Foundation Power Tools имеются следующие дополнительные правила:

• Правило Forbidden Patterns позволяет запретить добавление файлов с определёнными шаблонами в именах, например, Form1.cs.
• Правило Custom Path позволяет увеличить гранулярность применения правил в проекте сконфигурировав правила только для определённых частей структуры папок системы контроля версий.
• Правило Changeset Comments проверяет, что изменения сопровождаются комментариями.
• Правило Work Item Query проверяет, что все элементы работы, возвращаемые в результате определённого запроса, ассоциированы с файлами (более продвинутый вариант правила Work Items).

Среди правил, доступных в открытом доступе можно выделить:

• Правило Code Comment Checking проверяет код на наличие комментариев перед внесением изменений (работает для кода на C#/VB.NET).
• Правило Code Review Workflow проверяет, что каждый пакет изменений ассоциирован с элементом работы, являющимся заданием на инспекцию кода в состоянии "Выполнено". Это правило позволяет проводить процесс инспекции вносимых изменений в более формальном виде.
• Правило Merge/Branch Only удостоверяет, что все изменения происходят в результате объединения с другой веткой либо ответвления. Представляет особый интерес с точки зрения процесса конфигурационного управления. Позволяет, например, запретить вносить изменения напрямую в одну из ветвей (например, ветвь релиза). Вносить изменения в ветвь, защищенную таким правилом, можно только через интеграцию изменений из других ветвей.

Выбрать список правил, применяемых для командного проекта можно с помощью окна настройки системы контроля версий ( рис. 14.6).

увеличить изображение
Рис. 14.6. Редактирование правил вноса изменений

Следует заметить, что достаточно часто при разработке случаются ситуации, когда изменение необходимо срочно внести и на удовлетворение всех правил времени нет, либо конкретное правило не может быть выполнено по объективным причинам. В этом случае разработчик имеет право отменить правила для своего пакета изменений, написав при этом комментарий с объяснением причин отмены ( рис. 14.7).

Рис. 14.7. Диалог Policy Failure