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

В предыдущей части мы рассмотрели общую структуру файла описания рабочих элементов и увидели, что в нем приводятся ссылки на файлы описаний типов рабочих элементов, ссылки на файлы, содержащие запросы, а также приведены задачи, которые превентивно выставляются разработчикам во время создания проекта. Думаю, что теперь любой разработчик при желании сможет самостоятельно определить и список рабочих элементов, и поставить задачи для проекта. Однако, пока еще непонятно, что же представляют собой непосредственно файлы описания типов рабочих элементов. В этой статье мы и постараемся разобраться, что к чему, каким образом взаимодействуют между собой элементы файлов. Главное, мы постараемся увидеть в Visual Studio значения элементов, описанных в файлах описания рабочих элементов.

Сразу оговорюсь, что я разобрал для сравнения всего лишь несколько файлов. Их содержимое, разумеется, показательно, но я не могу гарантировать, что описал все возможные варианты. Хотя, с другой стороны, в отсутствие какой-либо информации о схеме xml-файлов… Те схемы данных, которые я описываю, получены при помощи xsd. Кроме того, я не буду упоминать о тех полях, которые присваиваются автоматически, например, идентификаторах поля.

Итак, если взять файл, описывающий рабочий элемент, то мы увидим, что его содержимым является единственный элемент типа WITD (вероятно, Work Item Type Definition). Ниже приведены примеры этого элемента, взятые из разных файлов:

<witd:WITD application="Work item type editor" version="1.0"

xmlns:witd="http://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">

<WITD application="Work item type editor" version="1.0">

Думаю, понятно, что в данных случаях важен просто сам факт наличия элемента WITD. Внутри элемента WITD также находится единственный элемент типа WORKITEMTYPE. Единственным атрибутом этого файла является name:

<WORKITEMTYPE name="Task">

<WORKITEMTYPE name="SDL Task">

<WORKITEMTYPE name="Bug">

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

У элемента WORKITEMTYPE могут быть четыре дочерних элемента – DESCRIPTION, FIELDS, WORKFLOW и FORM. Рассмотрим их подробнее.

Назначение элемента DESCRIPTION очевидно из его названия – этот элемент хранит в себе словесное описание рабочего элемента. Приведу примеры:

<DESCRIPTION>Tracks work that needs to be done.</DESCRIPTION>

<DESCRIPTION>Includes information to track an SDL task through the development lifecycle</DESCRIPTION>

<DESCRIPTION>Describes a divergence between required and actual behavior, and tracks the work done to correct the defect and verify the correction.</DESCRIPTION>

<DESCRIPTION>Includes information to track the work to resolve the Bug and to verify its resolution.</DESCRIPTION>

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

FIELDS хранит в себе множество элементов типа FIELD. Другими словами, этот элемент определяет список полей, которые используются данным рабочим элементом. К этому списку и его формату мы еще вернемся.

Теперь попробуем разобраться с элементов WORKFLOW. Исходя из его схемы, он может состоять из двух элементов – STATES и TRANSITIONS. В элементе STATES хранится информация о возможных состояниях объекта, при этом каждое состояние представлено элементом STATE. А в элементе TRANSITIONS хранится информация о том, в результате каких событий рабочий элемент может перейти из одного состояния в другое. Очевидно, что каждый переход описан одним элементом типа TRANSITION.

Элемент STATE имеет только один атрибут – строковое поле value. В нем можно определить состояние, в котором находится рабочий элемент, например, "Active”, “Pending”, “Closed” и т. д. Приведу примеры определения этого атрибута:

<STATE value="Active">

<STATE value="Resolved">

<STATE value="Closed" />

Понятно, что разработчик шаблона процесса (точнее, тот, кто пишет шаблон рабочего элемента) может определить столько состояний рабочего элемента, сколько считает нужным.

Кроме того, элемент типа STATE хранит в себе список полей, которые будут изменены при переходе в другое состояние. Никакие другие поля при нахождении элемента в данном состоянии изменяться не могут. Например, рабочий элемент Bug, соответствующий обнаруженной в приложении ошибке, может находиться в состоянии “Active”. Из этого состояния он может перейти в состояние “Resolved” (причина ошибки выяснена, но еще не устранена, так как устранение требует времени) и “Closed” (все, ошибка устранена). В соответствии с этим у состояние “Active” могут быть изменены поля “ResolvedDate” (дата определения причины ошибки), “ResolvedBy” (кем была выявлена причина ошибки), “ResolvedReason” (описание причины ошибки), “ClosedDate” (дата устранения ошибки) и “ClosedBy” (кем была устранена ошибка). Элемент STATE также хранит в себе значения, которые будут присвоены данным полям при переходе в это состояние. Ниже я привожу пример определения состояния “Active” элемента Bug, входящего в состав шаблона SDL:

<STATE value="Active">

  <FIELDS>

    <FIELD refname="Microsoft.VSTS.Common.ResolvedDate">

      <EMPTY/>

    </FIELD>

    <FIELD refname="Microsoft.VSTS.Common.ResolvedBy">

      <EMPTY/>

    </FIELD>

    <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">

      <EMPTY/>

    </FIELD>

    <FIELD refname="Microsoft.VSTS.Common.ClosedDate">

      <EMPTY/>

    </FIELD>

    <FIELD refname="Microsoft.VSTS.Common.ClosedBy">

      <EMPTY/>

    </FIELD>

  </FIELDS>

</STATE>

Таким образом, пре переходе в состояние “Active” значения перечисленных в нем полей попросту сбрасываются. Другой пример – состояние “Closed”. Оно является “конечным”, из него нет переходов и, соответственно, оно не изменяет значения полей. Это отражается и в его определении:

<STATE value="Closed">

</STATE>

Однако, в этой логике есть несколько  пробелов. С одной стороны, мы не знаем, из какого состояние в какое может переходить элемент. Например, если у элемента есть состояние “Waiting” (ожидание), то можно ли из этого состояния переходить сразу же в состояние, скажем, “Closed” или же сначала необходимо перейти в состояние “Resolved”, а только потом в “Closed”? Кроме того, невозможно определить, из какого состояния, кто и по какой причине перевел элемент в данное состояние. Для отслеживания этих данных используются элементы типа TRANSITION.

У элемента типа TRANSITION есть два атрибута – строковые поля “from” и “to”. Их значениями должны являться, соответственно, названия состояний, из которого в которое перешел элемент (значения атрибутов value полей типа STATE).

Помимо этого, каждый элемент типа TRANSITION включает в себя элементы REASONS и FIELDS. REASONS в свою очередь, включает в себя элементы типа REASON (их может быть много) и DEFAULTREASON (он должен быть единственным). Другими словами, элемент типа REASONS представляет собой список возможных причин перехода из одного состояния в другое, при этом одна из причин предлагается по умолчанию. FIELDS определяет список полей, изменяющих значение при переходе из состояния в состояние, а также присваиваемые этим полям значения. Например, факт создания нового элемента типа Bug может быть описан следующим образом:

<TRANSITION from="" to="Active">

  <REASONS>

    <DEFAULTREASON value="New"/>

    <REASON value="Build Failure"/>

  </REASONS>

  <FIELDS>

    <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">

      <COPY from="currentuser"/>

      <VALIDUSER/>

      <REQUIRED/>

    </FIELD>

    <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">

      <SERVERDEFAULT from="clock"/>

    </FIELD>

    <FIELD refname="System.AssignedTo">

      <DEFAULT from="currentuser"/>

    </FIELD>

  </FIELDS>

</TRANSITION>

Понятно, что в данном случае возникновение ошибки может быть связано либо с невозможностью сборки проекта, либо просто с фактом обнаружения ошибки разработчиком или тестером. Время возникновения ошибки и обнаруживший ее пользователь фиксируются автоматически, ошибка адресуется пользователю, обнаружившему ее. Еще пример – при переходе из состояние “Active” в состояние “Resolved” могут быть выбраны причины из следующего списка:

<REASONS>

  <DEFAULTREASON value="Fixed"/>

  <REASON value="Deferred"/>

  <REASON value="Duplicate"/>

  <REASON value="As Designed"/>

  <REASON value="Unable to Reproduce"/>

  <REASON value="Obsolete"/>

  <REASON value="SDL Exception"/>

</REASONS>

Итак, мы рассмотрели две – DESCRIIPTION и WORKFLOW – из четырех составляющих определения рабочего элемента. Теперь можно в целом представить себе, что же такое рабочий элемент и каким образом определяется логика его работы. В последующих статьях мы продолжим рассмотрение рабочего элемента.

Реклама


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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s