Заметки консультанта

Шамрай Александр Владимирович

Archive for Февраль 2015

Руководство по настройке шаблона процесса TFS. Сценарий 3 – Проверка уровня вложения пути области

Posted by Шамрай Александр на Февраль 16, 2015

Краткий обзор бизнес-проблемы

Этот сценарий как заставить пользователя выбрать путь области, который является по крайней мере «X» уровня вложения. Мы изменим существующий Product Backlog Item из шаблона MSF Scrum, чтобы включить необходимую проверку допустимости.

Что в этом руководстве?

  • Настройка определения типа рабочего элемента для задачи
  • Принудительный выбор уровня вложения «Х» для пути области
  • Реализация и развертывание

Настройка

Этот документ представляет собой решение для этого сценария из реальной жизни, когда для обеспечения бизнес правила рабочий элемент будет модифицирован. В пользовательский интерфейс добавляется новое поле для обеспечения проверки, и внутри рабочего элемента добавляется дополнительная логика для обеспечения проверки успеха или ошибки.

Мы возьмем шаблон рабочего элемента Product Backlog Item и настроим его. Эта настройка проверяет, что выбран правильный путь области:

  1. На форму будут выведены вкладка проверки допустимости или поле, сообщающие пользователю необходимые данные
  2. Запрещенное значение в сообщении проверки создаст подсказку в VS в верхней части рабочего элемента
  3. Пользователь может проверить сообщение для получения дополнительной информации
  4. После того, как пользователь выбирает допустимый Area Path, сообщение проверки обновляется допустимым значением; пользователь может теперь сохранить рабочий элемент

В центре подпрограммы проверки является поле сообщения. Во время изменений в пути области поле сообщения обновляется, чтобы указать, что выбранный путь области не соответствует желаемому критерию. Сообщение, которое мы представляем конечному пользователю, это запрещенное значение для этого поля. Это в свою очередь заставит Visual Studio отобразить предупреждающее сообщение в верхней части формы, сообщающее пользователю, чтобы необходимо сделать правильный выбор для поля Area Path.

Рисунок 24 – Пример сообщения об ошибке для области

Для целей этого руководства мы выполним следующую настройку Area Path.

Рисунок 25 – Пример настройки для пути области

Настройка позволит запретить пользователям выбирать корневой узел (FabrikamFiber), а также два узла второго уровня (Client и Web).

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

 

Шаги

Шаг Описание Сделано
1 Экспортировать тип рабочего элемента, который вы ходите модифицировать [ ]
2 Открыть файл типа рабочего элемента для настройки [ ]
3 Определить идентификаторы запрещенных путей области [ ]
4 Создать новое поле AreaPathValidation со специальным правилом [ ]
5 Создать вкладку Validation Info, чтобы отображать проблему проверки в рабочем элементе, и добавить созданное поле AreaPathValidation на новую вкладку Validation Info [ ]
6 Импортировать настроенный шаблон рабочего элемента [ ]
7 Протестировать настроенный рабочий элемент [ ]

Таблица 4 – Шаги решения

Реализация и развертывание

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

1. Первым шагом является экспорт типа рабочего элемента, который вы хотите изменить из конкретного командного проекта.

Чтобы выполнить это, мы можем использовать программу witadmin:

Перейдите в Пуск-> Microsoft Visual Studio 2012-> Visual Studio Tools и откройте Developer Command Prompt

Выполните следующую команду для экспорта типа в файл xml:

witadmin exportwitd /collection:http://tfsserver:8080/tfs/CollectionName /p:TeamProjectName /f:WorkItemTypePathName.xml /n:Task

2. Откройте файл типа рабочего элемента для настройки, например:


Рисунок 26 – Первоначальный тип рабочего элемента Product BackLog Item

3. Определите идентификатор области для ограничиваемой области

Для определения идентификаторов области различных путей области, которые мы хотим сделать неактивными, мы создадим дополнительный отчет, который включает информацию, необходимую для определения необходимой информации. Для создания нового запроса, нажмите ссылку Новый запрос в разделе запросы Team Explorer.

Альтернативно, если вы имеете доступ к базе данных, вы можете запустить следующий запрос:

select tbl_nodes.path, treenodes.id from treenodes inner join tbl_nodes on convert(varchar(36), tbl_nodes.id) = treenodes.CSSNodeId order by tbl_nodes.path

Рисунок 27 – Запросы в Team Explorer

Это запустит редактор запросов

Рисунок 28 – Редактор запросов

Нажмите кнопку Параметры столбца на панели инструментов конструктора запросов. Это отобразит окно Параметры столбцов, которое позволит вам обновлять столбцы, которые будут включены в результат запроса, при его выполнении. Измените столбцы для включения AreaID и Area Path (я включил также IterationID и Iteration Path). Нажмите кнопку ОК.

Рисунок 29 – Настройка столбцов в редакторе запросов

Далее нажмите кнопку Выполнить на панели инструментов редактора запросов. Результирующий запрос предоставит вам список путей области и идентификаторы области. Посмотрите в результирующих элементах пути области, которые вы хотите запретить.

Рисунок 30 – Запрос путей и идентификаторов области

В нашем случае пути области, которые мы хотим запретить, перечислены в таблице ниже с их идентификаторами. Эта информация будет меняться в зависимости от вашей конкретной конфигурации. Если пути области, которые вы хотите запретить не перечислены здесь, можно либо создать новый рабочий элемент и поместить его в отсутствующий путь области, либо временно обновить существующий.

Путь итерации Идентификатор итерации
FabrikamFiber 19
FabrikamFiber\Client 32
FabrikamFiber\Web 33

Таблица 5 – Идентифицированные пути области для запрета

В этом случае AreaID – 19,32 и 33. Значения и количество AreaID будет варьироваться в зависимости от вашей конкретной конфигурации Team Foundation Server

4. Создайте новое поле AreaPathValidation с определенным правилом.

Рисунок 31 – Поле AreaPathValidation

<FIELD name=»Area Path Validation» refname=»Demo.AreaPathValidation» type=»String»>

<COPY fromvalue» valueNo Errors» />

<PROHIBITEDVALUES>

<LISTITEM valueArea path has to be at least 3 levels deep» />

</PROHIBITEDVALUES>

<WHEN fieldSystem.AreaID» value19«>

<COPY fromvalue» valueArea path has to be at least 3 levels deep» />

</WHEN>

<WHEN fieldSystem.AreaID» value=»32″>

<COPY fromvalue» valueArea path has to be at least 3 levels deep» />

</WHEN>

<WHEN fieldSystem.AreaID» value33«>

<COPY fromvalue» valueArea path has to be at least 3 levels deep» />

</WHEN>

</FIELD>

Исходный код 7 – Поле AreaPathValidation

5. Создайте Вкладку Validation Info для отображения проблем проверки в рабочем элементе и добавьте на нее созданное поле AreaPathValidation.

Рисунок 32 – AreaPathValidation добавленное на форму

<Tab LabelValidation Info«>

<Group LabelValidation Errors«>

<Column PercentWidth100«>

<Control TypeFieldControl« FieldNameDemo.AreaPathValidation«
LabelArea path validation: » LabelPositionLeft» ReadOnlyTrue» />

</Column>

</Group>

</Tab>

Исходный код 8 — AreaPathValidation добавленное на форму

6. Импортируйте новый настроенный шаблон рабочего элемента

Выполните следующую команду импорта:

witadmin importwitd /collection:http://tfsserver:8080/tfs/CollectionName /f:WorkItemTypePathName.xml /p:TeamProjectName

7. Протестируйте настроенный рабочий элемент

Создайте новый рабочий элемент Product Backlog Item, обратите внимание, что появилась новая вкладка Validation Info. Вы также заметите, что присутствует индикатор ошибки проверки. Это, потому что область в настоящее время присвоена FabrikamFiber (корневой узел иерархии пути области).

Рисунок 33 – Вкладка Validation Info

При нажатии на вкладку Validation Info вы можете оценить сообщение.

Рисунок 34 – Начальная ошибка проверки при создании нового Product Backlog Item

Заполните рабочий элемент, введя необходимые данные и убедитесь, что путь области неправильный, при этом появится сообщение об ошибке. Наконец при выборе пути области, которая считается действительной, как показано в ниже, исчезнет сообщение проверки.

Рисунок 35 – Заполненный новый Product Backlog Item с правильным Area Path

 

Итог

В этом пошаговом руководстве мы рассмотрели настройку шаблона процесса для типа рабочего элемента. Было показано как добавить поле, сделать его видимым на форме рабочего элемента, создать правило, которое обеспечит действительный Area Path, и определить AreaID и Area Path.

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

Реклама

Posted in Microsoft, Team Foundation Server, TFS Process Template Customization Guide, Visual Studio | Отмечено: , | Leave a Comment »

Руководство по настройке шаблона процесса TFS. Сценарий 2 – Принудительный выбор причины

Posted by Шамрай Александр на Февраль 11, 2015

Краткий обзор бизнес-проблемы

Сценарий позволяет пользователю выбрать причину при переходе рабочего элемента Task из состояния «TO DO» в состояние «Done».

Что в этом руководстве?

  • Настройка определения типа рабочего элемента для задачи
  • Принудительный выбор причины
  • Реализация и развертывание

Настройка

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

Мы возьмем шаблон рабочего элемента Task и настроим его. Когда пользователь перемещает рабочий элемент в состояние Done:

  1. Состояние изменяется из To Do в Done
  2. Поле Reason отображает сообщение с запросом значения
  3. Поле проверки будет отображаться на форме, сообщая пользователю о необходимых данных
  4. Во время изменения состояния сообщению проверки присваивается сообщение об ошибке (это также запрещенное значение)
  5. Запрещенное значение в сообщении проверки создаст подсказку в VS в верхней части рабочего элемента
  6. Пользователь может просмотреть сообщение проверки для получения дополнительной информации
  7. После того как пользователь выбирает правильную причину, сообщение проверки получает обновление до допустимого значения; Пользователь теперь может сохранить рабочий элемент

В центре подпрограммы проверки является поле сообщения. При переходе из состояния To Do в Done мы установим в поле сообщение, информирующее пользователя, что ему нужно сделать выбор. Сообщение, которое мы представляем для конечного пользователя, это запрещенное значение для этого поля. Что в свою очередь это заставит Visual Studio отобразить предупреждающее сообщение в верхней части формы, информируя пользователей, что нужно сделать выбор для в поле Reason.

Шаги

Шаг Описание Сделано
1 Экспортировать тип рабочего элемента, который вы ходите использовать как базовый для нового типа рабочего элемента [ ]
2 Отредактировать переход из To-Do в Done и установить новый ReasonSelectedValidation [ ]
4 Импортировать новый настроенный шаблон рабочего элемента [ ]
5 Протестировать настроенный тип рабочего элемента с измененными состояниями [ ]

Таблица 3 – Шаги решения

Реализация и развертывание

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

1. Первым шагом является экспорт типа рабочего элемента, который вы хотите изменить из конкретного командного проекта. Для этого примера мы будем использовать тип Task.xml.

Чтобы выполнить это, мы можем использовать программу witadmin:

Перейдите в Пуск-> Microsoft Visual Studio 2012-> Visual Studio Tools и откройте Developer Command Prompt

Выполните следующую команду для экспорта типа в файл xml:

witadmin exportwitd /collection:http://tfsserver:8080/tfs/CollectionName /p:TeamProjectName /f:ValidatedTask.xml /n:Task

2. Откройте файл типа рабочего элемента для настройки, например:


Рисунок 13 – Первоначальный тип рабочего элемента Task

3. Добавьте новое поле ReasonSelectedValidation со следующими правилами:

Рисунок 14 – Поле ReasonSelectedValidation

<FIELD nameReasonSelectedValidation» refnameDemo.ReasonSelectedValidation» typeString«>

<PROHIBITEDVALUES>

<LISTITEM valueYou must select a reason to close this task«> </LISTITEM>

</PROHIBITEDVALUES>

<HELPTEXT>You must select a reason when closing a task </HELPTEXT>

</FIELD>

Исходный код 3 – Поле проверки выбранной итерации

4. Создайте новую вкладку Validation Info для отображения проблем проверки внутри рабочего элемента и добавьте новое поле ReasonSelectedValidation на форму типа рабочего элемента.

Рисунок 15 – Поле ReasonSelectedValidation добавленное на форму рабочего элемента

<Tab LabelValidation Info«>

<Group LabelValidation Errors«>

<Column PercentWidth100«>

<Control TypeFieldControl» FieldNameDemo.ReasonSelectedValidation» LabelReason Selected» LabelPositionLeft» ReadOnlyTrue» />

</Column>

</Group>

</Tab>

Исходный код 4 — Поле ReasonSelectedValidation добавленное на форму рабочего элемента

Тут также нужно проверить, что поле System.Reason не настроено как доступное только для чтения (как бывает в случае с некоторыми из встроенных типов рабочих элементов). Ниже приводится то, что вам нужно найти:

Рисунок 16 — System.Reason как поле только для чтения

В этом случае поле помечено как только для чтения, поэтому этот атрибут нужно удалить, и результат будет следующим:

Рисунок 17 — System.Reason доступное для редактирования

5. Модифицируйте переход из состояния To Do в Done, установив поле ReasonSelectedValidation в неправильное значение

Рисунок 18 – Неправильное поле ReasonSelectedValidation при изменении состояния

<FIELDS>

<FIELD refnameDemo.ReasonSelectedValidation«>

<COPY fromvalue» valueYou must select a reason to close this task» />

</FIELD>

</FIELDS>

6. Отредактируйте секцию причин для обновления поля ReasonSelectedValidation значением без ошибки, когда причина установлена

Рисунок 19 – Изменение в переходах между состояниями

<REASONS>

<DEFAULTREASON valueSelect a Reason…» />

<REASON valueWork Finished«>

<FIELDS>

<FIELD refnameDemo.ReasonSelectedValidation«>

<COPY fromvalue» valueNo Errors» />

</FIELD>

</FIELDS>

</REASON>

<REASON valueObsolete«>

<FIELDS>

<FIELD refnameDemo.ReasonSelectedValidation«>

<COPY fromvalue» valueNo Errors» />

</FIELD>

</FIELDS>

</REASON>

<REASON value=»Deferred»>

<FIELDS>

<FIELD refnameDemo.ReasonSelectedValidation«>

<COPY fromvalue» valueNo Errors» />

</FIELD>

</FIELDS>

</REASON>

</REASONS>

7. Импортируйте новый настроенный шаблон рабочего элемента

Выполните следующую команду импорта:

witadmin importwitd /collection:http://tfsserver:8080/tfs/CollectionName /f:WorkItemTypePathName.xml /p:TeamProjectName

8. Протестируйте изменения состояний в настроенном рабочем элементе

Создайте новый рабочий элемент Task, обратите внимание, что появилась новая вкладка Validation Info.

Рисунок 20 – Вкладка Validation Info

Заполните рабочий элемент Task, указав необходимую, информацию и сохраните его. Это установит задачу в состояние To-Do. Ниже приведен пример заполненного рабочего элемента:

Рисунок 21 – новая заполненная задача

Измените состояние на Done, вы заметите, что Validation Info обновится сразу сообщением «You must select a reason to close the task».

Рисунок 22 – Рабочий элемент Task с ошибкой проверки

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

Рисунок 23 — Рабочий элемент Task с исправленной ошибкой проверки

Итог

В этом руководстве мы рассмотрели создание и настройку нового типа рабочего элемента шаблона процесса на основе встроенного типа рабочего элемента Task. Настройки показали, как добавить поле, сделать его видимым в пользовательском интерфейсе рабочего элемента, создать правила, гарантирующие, что требуется причина, если новый рабочий элемент был помечен как «Done».

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

Posted in Microsoft, Team Foundation Server, TFS Process Template Customization Guide, Visual Studio | Отмечено: , , | Leave a Comment »

Руководство по настройке шаблона процесса TFS. Сценарий 1 – Закрытие итерации

Posted by Шамрай Александр на Февраль 9, 2015

Краткий обзор бизнес-проблемы

Этот сценарий охватывает аспекты блокировки одной или нескольких итераций так, чтоб они больше не могли использоваться после завершения итерации. Мы изменим существующий Product Backlog Item из шаблона MSF Agile для включения необходимой проверки.

Что в этом руководстве?

  • Настройка шаблона процесса
  • Блокирование пути итерации
  • Реализация и развертывание

Настройка

Этот документ представляет собой решение для этого сценария из реальной жизни, когда тип рабочего элемента должен быть изменен для соблюдения бизнес-правил. В пользовательский интерфейс для обеспечения проверки добавляется новое поле и внутри рабочего элемента добавляется дополнительная логика для обеспечения проверки успеха или ошибки.

Мы возьмем шаблон рабочего элемента Product Backlog Item и настроим его. Эта настройка обеспечит проверку, что выбран допустимый, активный путь итерации, проще говоря, он проверен.

  1. Вкладка проверки или поле будут отображаться на форме, сообщая пользователю о необходимых данных
  2. Запрещенное значение в сообщении проверки создаст подсказку в VS в верхней части рабочего элемента
  3. Пользователь может проверить предупреждение для получения дополнительной информации
  4. После того, как пользователь выберет правильный Iteration Path, сообщение проверки обновится как допустимое значение; Пользователь теперь может сохранить рабочий элемент

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

Рисунок 1 – Пример сообщения с ошибкой для итерации

В этом руководства мы будем использовать следующие установки итерации.

Рисунок 2 – Пример настройки итераций

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

Шаги

Шаг Описание Сделано
1 Экспортировать тип рабочего элемента, который вы ходите настроить [ ]
2 Определить идентификатор итерации для ограничиваемой итерации [ ]
3 Отредактировать экспортированный файл xml и применить изменения [ ]
4 Импортировать настроенный шаблон рабочего элемента [ ]
5 Протестировать настроенный тип рабочего элемента [ ]

Таблица 1 – Шаги решения

Реализация и развертывание

Проверка реализуется путем создания нового поля, которое отображается в пользовательском интерфейсе, с некоторыми правилами

1. Первым шагом является экспорт типа рабочего элемента, который вы хотите изменить из конкретного командного проекта.

Чтобы выполнить это, мы можем использовать программу witadmin:

Перейдите в Пуск-> Microsoft Visual Studio 2012-> Visual Studio Tools и откройте Developer Command Prompt

Выполните следующую команду для экспорта типа в файл xml:

witadmin exportwitd /collection:http://tfsserver:8080/tfs/CollectionName /p:TeamProjectName /f:ProductBacklogItem.xml /n: ProductBacklogItem

2. Откройте файл типа рабочего элемента для настройки, например:


Рисунок 3 – Первоначальный тип рабочего элемента Product Backlog Item

3. Определите идентификатор итерации для ограничиваемой итерации

Для определения идентификаторов итерации различных путей итерации, которые мы хотим сделать неактивными, мы создадим дополнительный отчет, который включает информацию, необходимую для определения необходимых данных. Для создания нового запроса, нажмите ссылку Новый запрос в разделе запросы Team Explorer.

Альтернативно, если вы имеете доступ к базе данных, вы можете запустить следующий запрос:

select tbl_nodes.path, treenodes.id from treenodes inner join tbl_nodes on convert(varchar(36), tbl_nodes.id) = treenodes.CSSNodeId order by tbl_nodes.path

Рисунок 4 – Запросы в Team Explorer

Это запустит конструктор запросов

Рисунок 5 – Редактор запросов

Нажмите кнопку Параметры столбца на панели инструментов редактора запросов. Это отобразит окно Параметры столбцов, которое позволит вам обновлять столбцы, которые будут включены в результат запроса, при его выполнении. Измените столбцы для включения IterationID и Iteration Path (я включил также AreaID и Area Path). Нажмите кнопку ОК.

Рисунок 6 – Настройка столбцов в редакторе запросов

Далее нажмите кнопку выполнить на панели инструментов редактора запросов. Результирующий запрос предоставит вам список путей итерации и идентификаторы итерации. Посмотрите в результирующих элементах пути итерации, которые вы хотите запретить.

Рисунок 7 – Запрос путей и идентификаторов итераций

В нашем случае пути и идентификаторы итерации, которые мы хотим запретить, перечислены в таблице ниже. Эта информация будет меняться в зависимости от конкретной конфигурации. Если пути итерации, которые вы хотите запретить не перечислены здесь, можно либо создать новый рабочий элемент и поместить его в отсутствующий путь итерации, либо временно обновить существующий.

Путь итерации Идентификатор итерации
FabrikamFiber 19
FabrikamFiber\Iteration 0 38

Таблица 2 – Идентифицированные пути итерации для запрета

В этом случае IterationID — 19 и 38. Значения и количество IterationID будет варьироваться в зависимости от конкретной конфигурации Team Foundation Server

4. Создайте новое поле IterationPathValidation с определенным правилом.

Когда закрыты дополнительные итерации, выделенный раздел в PBI.xml ниже нужно будет скопировать с новым IterationID, чтобы блокировать эти дополнительные итерации.

Рисунок 8 – Поле IterationPathValidation

<!—
************* Adding New Field **************************** —>

<FIELD nameIteration Path Validation» refnameDemo.IterationPathValidation» typeString» reportabledimension» >

<COPY fromvalue» value=»» />

<PROHIBITEDVALUES>

<LISTITEM valueIteration path has to be at least 2 levels deep» />

<LISTITEM valueThe selected iteration has been completed. Log Product Backlog Items against a future iteration» />

</PROHIBITEDVALUES>

<WHEN fieldSystem.IterationID» value=»3«>

<COPY fromvalue» valueIteration path has to be at least 2 levels deep» />

</WHEN>

<WHEN fieldSystem.IterationID» value18«>

<COPY fromvalue» valueThe selected iteration has been completed. Log Product Backlog Items against a future iteration» />

</WHEN>

</FIELD>

<!— END ************* Adding New Field **************************** —>

Исходный код 1 – Поле проверки пути итерации

Текст сообщения об ошибке вы используете в зависимости от информации, который вы хотите передать пользователям.

Создайте вкладку Validation Info для отображения проблем проверки в рабочем элементе и добавьте на нее созданное поле IterationPathValidation.

Рисунок 9 – IterationPathValidation добавленное на форму

<Tab LabelValidation Info«>

<Group LabelValidation Errors«>

<Column PercentWidth100«>

<Control FieldNameDemo.IterationPathValidation» TypeFieldControl» LabelIteration path validation: » LabelPositionLeft» ReadOnlyTrue» />

</Column>

</Group>

</Tab>

Исходный код 2 — IterationPathValidation добавленное на форму

5. Импортируйте новый настроенный шаблон рабочего элемента

Предварительно, как хорошая практика, вы можете проверить XML определение перед импортом в ваш Командный Проект:

witadmin importwitd /collection:http://tfsserver:8080/tfs/CollectionName /f:ProductBacklogItem.xml /p:TeamProjectName /v

Выполните следующую команду импорта:

witadmin importwitd /collection:http://tfsserver:8080/tfs/CollectionName /f:ProductBacklogItem.xml /p:TeamProjectName

6. Протестируйте настроенный рабочий элемент

Создайте новый рабочий элемент Product Backlog Item, обратите внимание, что появилась новая вкладка Validation Info. Вы также заметите, что присутствует индикатор ошибки проверки. Это потому, что итерация в настоящее время присвоена FabrikamFiber (корневой узел иерархии пути итерации).

Рисунок 10 – Вкладка Validation Info

При нажатии на вкладку Validation Info мы увидим отображаемое на ней сообщение.

Рисунок 11 – Начальная ошибка проверки при создании нового Product Backlog Item

Заполните рабочий элемент, введя необходимые данные и убедитесь, что путь итерации заполнен значением закрытой или заблокированной итерации, при этом появится сообщение об ошибке. Наконец при выборе пути итерации, которая считается действительной, как показано в ниже, исчезнет сообщение проверки.

Рисунок 12 – Заполненный новый Product Backlog Item с правильным Iteration Path

Итог

В этом пошаговом руководстве мы рассмотрели настройку шаблона процесса для типа рабочего элемента. Было показано как добавить поле, сделать его видимым на форме рабочего элемента, создать правило, которое обеспечит действительный Iteration Path, и определить IterationID и Iteration Path.

Т.к. этот вид настройки типа рабочего элемента делается в одном проекте, а если у вас есть намерение иметь такую настройку для будущих командных проектов, необходимо обновить шаблон процесса. Пожалуйста, смотрите http://msdn.microsoft.com/en-us/library/ms194972.aspx о том, как обновить шаблон процесса.

Posted in Microsoft, Team Foundation Server, TFS Process Template Customization Guide, Visual Studio | Отмечено: , , | Leave a Comment »

Практическое руководство по отчетности TFS – Часть 2. Data Warehouse

Posted by Шамрай Александр на Февраль 5, 2015

Переведено руководство от рейнджеров по работе с отчетами. Оригинал: https://vsarreportguide.codeplex.com/

Содержание

Posted in Microsoft, Team Foundation Server, TFS Practical Reporting Guide, Visual Studio | Отмечено: , , | Leave a Comment »

Практическое руководство по отчетности TFS. Заключение

Posted by Шамрай Александр на Февраль 5, 2015

На этом завершается наше путешествие по хранилищу данных Team Foundation Server. Мы затронули теорию и познакомили вас с хранилищем данных и отчетностью. Мы рассмотрели различные упражнения в руководстве и провели вас через теорию, проектирование и практическое использования хранилища данных TFS, чтобы активно наблюдать и обнаруживать проблемы состояния среды TFS.

Мы надеемся, что вы оцените эти технологии и найдете это руководство полезным.

Искренне

The Microsoft Visual Studio ALM Rangers

Posted in TFS Practical Reporting Guide | Отмечено: , , | Leave a Comment »

Практическое руководство по отчетности TFS. Введение

Posted by Шамрай Александр на Февраль 5, 2015

Добро пожаловать в руководство по отчетности TFS, где мы, Рейнджеры ALM, возьмем вас в увлекательное путешествие, чтобы вы открыли для себя интересные и мощные функции отчетности, предоставляемые сервером Team Foundation Server.

Это руководство фокусируется на предоставлении практических рекомендаций и примеров, которые позволят пользователям Team Foundation Server создавать полезные отчеты, используя TFS Data Warehouse и основываясь на реальных сценариях.

Целевая аудитория

Мы ожидаем, что большинство нашей аудитории будут разработчики. Однако руководство предназначено для всех, от разработчика до администратора, оно объяснит, как создать и использовать отчеты, которые помогают отслеживать, что Team Foundation Server и связанные проекты хорошо настроены и в рабочем состоянии. Руководство предполагает наличие базовых знаний о Team Foundation Server и понимания отчетности, иными словами, пользователи Team Foundation Server среднего уровня и продвинутые.

Что вам понадобится

Для этого руководства необходимы следующие поддерживаемые компоненты:

  • Visual Studio 2012, 2013
  • Team Foundation Server 2010, 2012, 2013
  • Microsoft Office Excel
  • SQL Server Business Intelligence Development Studio

Рейнджеры Visual Studio ALM

Рейнджеры Visual Studio ALM представляют собой особую группу из членов группы продуктов Visual Studio, Майкрософт, Microsoft Most Valuable Professionals (MVP) и лидеров сообщества Visual Studio. Их миссия заключается в обеспечении внешних решений для отсутствующих возможностей и руководств. Постоянно пополняемое содержимое Рейнджеров доступно онлайн.

Участники

Грант Холлидей, Хамид Шахид, Джесси Хоувинг, Джим Зубрит, Маттиас Скольд, Рамкумар Прасанна, Приянка Джанардхан.

Использование исходного кода для примера, ошибки и поддержка

Весь исходный код данного руководстве доступен для скачивания на домашней странице Практического руководства отчетности TFS, где мы также предоставляем последние исправления и обновления. Скачайте файл eBook2-Package.exe.

Дополнительные ресурсы Рейнджеров ALM

Информация о Рейнджерах ALM – http://aka.ms/vsarunderstand

Решения Рейнджеров Visual Studio ALM – http://aka.ms/vsarsolutions

Posted in TFS Practical Reporting Guide | Отмечено: , , | Leave a Comment »

Практическое руководство по отчетности TFS. Предисловие

Posted by Шамрай Александр на Февраль 5, 2015

Одним из ключевых предложений Team Foundation Server был единое представление данных, пересекающее весь спектр управления жизненным циклом приложений (ALM). Из коробки мы создали широкий спектр отчетов, использующих эти данные, чтобы помочь дать понимание о состоянии проекта. Очевидно, что невозможно для команды продукта построить все отчеты или предвидеть, каким образом данные могут использоваться в каждой команде. Рейнджеры ALM проделали большую работу по расширению области существующих отчетов через обеспечение дополнительного понимания оценки состояния, фокуса команды и реакции для заказчиков. Эти отчеты могут послужить инструментами для вашей команды, которые помогают улучшить эффективность и стать более предсказуемыми для ваших заказчиков. Как владелец продукта команды для отчетности, я всегда ищу новые, углубленные способы сделать команду более продуктивной, и мы ценим обратную связь на то, как эти отчеты улучшили ваши команды и какие дополнительные идеи вы имеете для отчетов, которые мы хотим в будущем разработать.

Джастин Маркс – старший руководитель программы Cloud Dev Services

Posted in TFS Practical Reporting Guide | Отмечено: , , | Leave a Comment »

 
%d такие блоггеры, как: