Формат и содержание файла описания рабочих элементов в TFS’е (часть 1)

Вы все работаете с TFS’ом. Наверное, вы видели в Team Explorer’е такой элемент, как Work Items. Сегодня я захотел, во-первых, сам разобраться, что к чему в этом элементе, а затем и рассказать о том, в чем же я разобрался.

Итак, рабочие элементы определены в шаблоне процесса в файле с именем WorkItems.xml. Давайте попробуем в нем разобраться. Естественно, для всех экспериментов необходим TFS. Однако любой может загрузить и установить у себя версию TFS 2010 Beta 2 и поупражняться на ней. Эту версию TFS’а можно взять у Юрия.

Теперь нам необходимо определить, о чем идет речь в файле WorkItems.xml. Для этого загрузим в TFS шаблон процесса SDL (Security Development Lifestyle) с этой странички. Загрузили? Что ж, создадим два командных проекта (в Visual Studio. Для того, чтобы понять, как создается командный проект, посмотрите на рисунок ниже:

При создании одного командного проекта выберите шаблон процесса “MSF for Agile Software Development…”, а при создании второго – “Microsoft Security Development Lifecycle”.

А теперь, когда вы будете создавать свои собственные проекты, “привяжите” их к командным проектам, указав при создании собственного проекта необходимость использовать средство контроля версий. При этом укажите те же директории, которые вы указали при создании командных проектов. Все, командные проекты созданы.

Откройте Team Explorer. Щелкните правой кнопкой мыши на элементе “Work Items” проекта, созданного по шаблону “Agile”. На отображение будет выдано меню:

Таким образом, видно, что в шаблоне Agile есть шесть типов рабочих элементов. Проделаем ту же операцию для шаблона SDL:

А в этом случае рабочих элементов всего четыре. Разница очевидна. Теперь заглянем в файлы WorkItems.xml обоих шаблонов. Вот что мы увидим в шаблоне Agile:

<taskXml>

<WORKITEMTYPES>

<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Bug.xml"/>

<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\SharedStep.xml"/>

<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Task.xml" />

<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\TestCase.xml" />

<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\UserStory.xml" />

<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Issue.xml" />

</WORKITEMTYPES>

</taskXml>


А вот что находится в шаблоне SDL:

<taskXml>

<WORKITEMTYPES>

<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Bug.xml" />

<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Task.xml" />

<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\SDL Task.xml" />

<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Security Code Review.xml" />

</WORKITEMTYPES>

</taskXml>

Я, естественно, не дизассемблировал TFS, но уверен, что подобные совпадения случайными не бывают. Итак, какие выводы мы можем сделать из того, что мы видим? Во-первых, обратим внимание на то, что к файлам Bug.xml и т. п. пути указаны относительно директории более высокого уровня. Следовательно, скорее всего в этой директории находится какой-то файл, который и ссылается на файл WorkItems.xml. Взглянем – в этой директории находится файл шаблона процесса ProcessTemplate.xml, в котором есть следующая строка:

<taskList filename="WorkItem Tracking\WorkItems.xml"/>

Таким образом, можно предположить, что шаблон проекта ProcessTemplate.xml сам определяет, где находятся файлы, описывающие части процесса. Таким образом, предлагаемая структура описания процесса, то есть директории Classification, WorkItem Tracking и т. д. созданы просто для удобства, их имена могут быть любыми. Следовательно, верить книжкам, в которых указано, что, мол, имена ДОЛЖНЫ быть такими, не стоит. Авторы попросту не удосужились проверить информацию.

Во-вторых, обратим внимание на то, что у каждого рабочего элемента есть свой шаблон. Эти шаблоны в данном случае находятся в файлах TypeDefinitions/*.xml. Предположим, что шаблон проекта представляет собой совокупность xml-файлов, организованных ЛОГИЧЕСКМ (но не физически) в некую иерархическую структуру. Допускаю (в данном случае это ПОКА НИЧЕМ НЕ ПОДТВЕРЖЕННОЕ ПРЕДПОЛОЖЕНИЕ), что вместо имен файлов могут быть и непосредственно описания элементов. Но в этом случае, понятно, размер файла будет очень большой и корректура его потребует немалых усилий по поиску того элемента, который необходимо изменить.

Так… Теперь “схлопнем” элементы, которые находятся внутри тега “tasks”. Мы увидим, что внутри тэга “tasks” присутствуют теги “WITs”, “WIs”, и “Queries”. Я обратил внимание на то, что в “умных” книжках написано, что, мол, “должны быть заданы три основных типа задач: типы рабочих элементов, запросы к рабочим элементам и экземпляры рабочих элементов”. Для проверки этого “должны” я со странички http://mpt.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=23959 загрузил шаблон процесса, который используется в Microsoft. Почему-то там только две задачи… Значит, опять врут “умные” книжки…

Но вернемся к нашим баранам. Взглянем, скажем, в проекте, созданном по шаблону SDL, какие запросы к проекту в нем присутствуют. Картина будет следующая:

Посмотрим теперь на текст файла WorkItems.xml:

<task id="Queries" name="Stored Query Definitions" plugin="Microsoft.ProjectCreationWizard.WorkItemTracking" completionMessage="Queries uploaded">

<dependencies>

<dependency taskId="WIs" />

<dependency taskId="WITs" />

</dependencies>

<taskXml>

<QUERIES>

<Query name="Active Bugs" fileName="WorkItem Tracking\Queries\ActiveBugs.wiq" />

<Query name="All Pending Security Code Reviews" fileName="WorkItem Tracking\Queries\AllPendingSecurityCodeReviews.wiq" />

<Query name="All SDL Tasks" fileName="WorkItem Tracking\Queries\AllSDLTasks.wiq" />

<Query name="All Security Bugs" fileName="WorkItem Tracking\Queries\AllSecurityBugs.wiq" />

<Query name="All Tasks" fileName="WorkItem Tracking\Queries\AllTasks.wiq" />

<Query name="All Work Items" fileName="WorkItem Tracking\Queries\AllWorkItems.wiq" />

<Query name="Closed Security Bugs" fileName="WorkItem Tracking\Queries\ClosedSecurityBugs.wiq" />

<Query name="My Resolved Code Reviews" fileName="WorkItem Tracking\Queries\MyResolvedCodeReviews.wiq" />

<Query name="My Work Items" fileName="WorkItem Tracking\Queries\MyWorkItems.wiq" />

<Query name="My Work Items for All Team Projects" fileName="WorkItem Tracking\Queries\MyWorkItemsAllTeamProjects.wiq" />

<Query name="Open and Blocking Security Bugs" fileName="WorkItem Tracking\Queries\OpenBlockingSecurityBugs.wiq" />

<Query name="Open SDL Tasks" fileName="WorkItem Tracking\Queries\OpenSDLTasks.wiq" />

<Query name="Open Security Bugs" fileName="WorkItem Tracking\Queries\OpenSecurityBugs.wiq" />

<Query name="Resolved Bugs" fileName="WorkItem Tracking\Queries\ResolvedBugs.wiq" />

<Query name="Resolved Security Bugs" fileName="WorkItem Tracking\Queries\ResolvedSecurityBugs.wiq" />

<Query name="SDL Exception Security Bugs" fileName="WorkItem Tracking\Queries\SDLExceptionSecurityBugs.wiq" />

<Query name="Untriaged Bugs" fileName="WorkItem Tracking\Queries\UntriagedBugs.wiq" />

</QUERIES>

</taskXml>

</task>

Вы верите в такие совпадения? Я – нет. Открыв любой файл с расширением “wiq”, мы увидим текст, подобный приведенному ниже:

<WorkItemQuery Version="1">

<Wiql>SELECT [System.Id], [System.WorkItemType], [System.AssignedTo], [System.CreatedBy],

[Microsoft.VSTS.Common.Priority], [System.Title], [System.Description] FROM WorkItems

WHERE [System.TeamProject] = @project AND [System.WorkItemType] = ‘Bug’ AND [System.State] = ‘Active’

ORDER BY [Microsoft.VSTS.Common.Priority], [System.Id]

</Wiql>

</WorkItemQuery>

Другими словами, в файлах с расширением “wiq” хранятся непосредственно запросы. Так… Запросы… Запросы к чему? Раз они написаны на языке SQL, то, скорее всего, к SQL-серверу. Следовательно, командные проекты хранятся как база данных SQL-сервера. Кроме того, предположим, что "@project” – это какой-то макрос. Следовательно, TFS использует список макросов, нужно только найти его… И еще. Раз в запросах нет ссылок на какие-нибудь файлы, то, значит, мы эту задачу просмотрели до конца. Таким образом, при разработке собственного шаблона или при модификации существующего мы теперь можем самостоятельно добавлять запросы или корректировать существующие.

Итак, мы разобрались фактически с тем, что представляет собой задача “WITs” (с нее мы начали, в ней определяются типы рабочих элементов) и задача “Queries”. Думаю, что теперь при необходимости каждый сможет откорректировать список типов рабочих элементов, список запросов и непосредственно запросы. Осталась только задача “WIs”. Что ж, разберемся и с ней…

Как оказалось, разобраться с задачей “WIs” нетрудно. Попробуем в проекте на шаблоне SDL сделать двойной щелчок на элементе “All Work Items”. На отображение будет выдано окно, подобное приведенному ниже:

Отсортируйте элементы в нем по возрастанию идентификатора. Что является первой задачей? А вот чему это соответствует:

<task id="WIs" name="WorkItems" plugin="Microsoft.ProjectCreationWizard.WorkItemTracking" completionMessage="Work items uploaded">

<dependencies>

<dependency taskId="WITs" />

</dependencies>

<taskXml>

<WORKITEMS>

<WI type="Task">

<FIELD refname="System.Title" value="Set up: Set Permissions" />

<FIELD refname="System.State" value="Active" />

<FIELD refname="System.Reason" value="New" />

<FIELD refname="Microsoft.VSTS.Common.Issue" value="No" />

<FIELD refname="Microsoft.VSTS.Common.ExitCriteria" value="Yes" />

<FIELD refname="System.Description" value="Add team members to one of the four security groups: Build Services, Project Administrators, Contributors, or Readers. To configure security, Right-click the team project in Team Explorer, and select ‘Team Project Settings,’ ‘Group Membership’." />

</WI>

….

Думаю, и в данном случае комментарии не нужны. В списке в VS – 4 “task’а” и 93 “SDL Task’а”, в файле WorkItems.xml — 4 “task’а” и 93 “SDL Task’а”, описания первого и последнего совпадают. Конечно, этого недостаточно, чтобы говорить о полном совпадении, но выше я уже говорил, что в подобные “случайности” не верю.

Итак, что же делает эта задача, “WIs”? А она просто-напросто в момент создания проекта создает те самые рабочие элементы, которые можно увидеть в VS. Таким образом, автор шаблона ПРИНУДИТЕЛЬНО выставляет участникам разработки проекта несколько (в данном случае достаточно много) задач, которые должны быть выполнены.

Кстати, в проекте по шаблону Agile вообще нет задачи “WIs”, зато там есть задача “Categories”. Что это такое, разберем позже. Зато сегодня мы узнали о том, что как определить перечень рабочих элементов, предоставить разработчикам проекта список возможных запросов, а также как выставить задачи разработчикам во время создания проекта. Теперь необходимо выяснить, как описывать рабочие элементы каждого типа. Но это тоже не сегодня…



Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s