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

Рис. 13.4. Закладка Policy Warnings.

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

106

Рис.13.5. Свойства набора изменений.

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

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

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

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

Work Items – предполагает, что каждый пакет изменений кроме файлов должен иметь ассоциацию с элементом работы;

Builds – проверяет, что перед внесением изменений разработчик убедился в собираемости проекта;

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

Code Analysis – выполняет статический анализ кода перед внесением изменений.

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

правила:

107

Правило 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 удостоверяет, что все изменения происходят в результате объединения с другой веткой либо ответвления. Представляет особый интерес с точки зрения процесса конфигурационного управления. Позволяет, например, запретить вносить изменения напрямую в одну из ветвей (например, ветвь релиза). Вносить изменения в ветвь, защищенную таким правилом, можно только через интеграцию изменений из других ветвей.

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

Рис. 13.6. Редактирование правил вноса изменений.

108

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

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

Управление ветками. Для поддержки конфигурационного управления в системе контроля версий TFS реализовано две команды: создание ветви (Branch) и интеграция ветвей (Merge). Эти команды доступны на файлах и папках в системе контроля версий. При выборе команды создания ветви открывается диалог (рис. 13.8), позволяющий выбрать путь, куда следует скопировать (ответвить) выбранные файлы. После выполнение этой команды в системе контроля версий по указанному пути создастся полная копия выбранных файлов.

Рис. 13.8. Создание новой ветви.

Заметим, что после создания ветви она не попадает автоматически на сервер. Чтобы ветвь попала на сервер и стала доступна всем, необходимо выполнить операцию внесения изменений (рис. 13.9).

109

Рис. 13.9. Внесение изменений ответвления.

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

110