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

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

Posts Tagged ‘guide’

Руководство по настройке шаблона процесса TFS. Сценарий 6 – Создание и Добавление пользовательских элементов управления для рабочего элемента

Posted by Шамрай Александр на Октябрь 13, 2015

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

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

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

  • Создание пользовательского элемента управления в Visual Studio
  • Добавление поля(ей) для рабочего элемента
  • Создание xml файла расширения wicc
  • Развертывание элемента управления для рабочего элемента
  • Загрузка пакета с пользовательским элементом управления

Настройка

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

Для настройки мы будем использовать шаблон рабочего элемента Bug, в который будет добавлен пользовательский элемент управления, который должен присутствовать в Visual Studio, Web Access, Test Manager и Team Explorer Everywhere (мы не будем объяснять, как это выполняется для Team Explorer Everywhere, но пакет включает в себя исходный код для Team Explorer Everywhere).

Шаги

Шаг Описание Сделано
1 Создание «настольного» элемента управления в Visual Studio [ ]
2 Создание элемента управления для Web Access [ ]
3 Экспортирование необходимого типа рабочего элемента [ ]
4 Открытие необходимого типа рабочего элемента для настройки [ ]
5 Добавление одного или нескольких полей для типа рабочего элемента [ ]
6 Импортирование необходимого типа рабочего элемента [ ]
7 Создание xml файла с расширением wicc [ ]
8 Инсталлирование пользовательского элемента управления [ ]
9 Загрузка пакета с пользовательским элементом управления [ ]
10 Тестирование пользовательского элемента управления в Visual Studio IDE и Web Access [ ]

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

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

1. Создание «настольного» элемента управления в Visual Studio

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

Пользовательский элемент управления является по существу обычным элементом управления Windows Forms. Он является производными от Control и реализует IWorkItemControl. Это будет определять интерфейс между хостом — Team Explorer или Test Manager — и самим пользовательским элементом управления. Мы можем получить доступ к визуализируемому рабочему элементу, получить/установить значение полей и получать события, когда некоторые вещи происходят в рабочем элементе.

To implement a work item custom control all we need to do is implement the <see cref=»Microsoft.TeamFoundation.WorkItemTracking.Controls.IWorkItemControl»/>

Рисунок 47 – Создание пользовательского элемента управления в Visual Studio

Весь исходный код для элемента управления «флажок» включен в загрузки для руководства.

2. Создание элемента управления Web Access

Начиная с Dev11 способ создания пользовательских элементов управления Web Access резко изменился. Ранее элементы управления Web Access писались как элементы управления ASP.NET и выполнялись внутри веб-сервера. В этой версии элементы управления были переделаны и теперь выполняются исключительно в браузере (элементы управления устанавливаются как расширения и Web Access развертывает код среди всех экземпляров уровня приложения).

Для реализации элемента управления под веб создайте файл (файл должен называться module.min.js, где module — это имя вашего типа элемента управления).

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

Рисунок 48 – Создание пользовательского элемента управления для Web Access

Нашей анонимной функции следует реализовать несколько функций. Мы не будем перечислить их все. Но опишем наиболее важные (вы можете просмотреть всю реализацию в общем пакете).

Конструктор (Рис. 49) инициализирует наш элемент управления.

Рисунок 49 – Реализация конструктора элемента управления

Выполняется наследование от WorkItemControl и реализация необходимых методов (таких как _init, где мы создаем разметку для нашего элемента управления, invalidate, где мы реализуем обратный вызов, который вызывается при изменении значения нашего поля).

Рисунок 50 – Наследование от WorkItemControl

В теле анонимного метода следует вызывать TFS. WorkItemTracking.Controls.registerWorkItemControl с двумя параметрами (Рис. 51) имя нашего модуля и объект с нашей реализацией. В конце мы возвращаем массив с объектом, который содержит реализацию элемента управления.

Рисунок 51 – Регистрация элемента управления и возврат реализации

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

<WebAccess version11.0«>

<plugin nameALM Rangers CheckBox Custom Control» vendorMicrosoft ALM Rangers» moreinfohttp://go.microsoft.com/fwlink/?LinkID=230946» version1.0.0» >

<modules >

<module namespaceMicrosoft.ALMRangers.CheckBoxControl» loadAfterTFS.WorkItemTracking.Controls«/>

</modules>

</plugin>

</WebAccess>

Исходный код 18 – manifest.xml элемента управления «флажок» для Web Access

Манифест регистрирует модуль, реализующий элемент управления, модули (ядра веб-доступа), от которых зависит элемент управления и некоторые метаданные для отображения в консоли администрирования.

Архивируем оба файла (javascript и файл манифеста) в один zip-файл, и элемент управления готов к использованию.

3. Следующим шагом является экспорт типа рабочего элемента (bug.xml), который вы хотите изменить в определенном командном проекте, с использованием команды «witadmin exportwitd» .

Чтобы выполнить это, мы можем использовать программу 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:WorkItemTypeName

4. Далее необходимо открыть файла типа рабочего элемента для настройки, например:

Рисунок 52 – Оригинальный тип рабочего элемента Bug

5. Добавить одно или несколько полей в тип рабочего элемента

Добавим логическое поле в тип рабочего элемента.

<FIELD nameBool Sample» refnameALMRangers.Bool» typeBoolean«>

<HELPTEXT>bool used as a boolean variable for purposes of a checkbox</HELPTEXT>

</FIELD>

Исходный код 19 – Добавление логического поля

Добавим элемент управления «Checkbox» в секцию «Layout».

<Control TypeMicrosoft.ALMRangers.CheckBoxControl» FieldNameALMRangers.Bool» NameMyControlName» LabelCheckbox Demo» LabelPositionLeft» />

Исходный код 20 – Добавление элемента управления «флажок»

Примечание

Вы можете использовать несколько разметок формы для различных клиентов, добавив атрибут Target в разделе Layout.

  • Используйте Winfowms для Team Explorer/Test Manager
  • Web для веб-доступа
  • JavaSWT или Teamprise для Team Explorer Everywhere

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

Рисунок 53 – Логические поле

Рисунок 54 – Размещение логического поля

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

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

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

7. Создайте XML файл с наименованием Microsoft.ALMRangers.CheckBoxControl.wicc.

Вы должны создать wicc файл с использованием значения для Control Type, чтобы идентифицировать Work Item Custom Control, в нашем случае мы должны дать название Microsoft.ALMRangers.CheckBoxControl.wicc.

Этот файл должен содержать имя файла сборки, а также полное имя (т.е. пространство имен и имя класса).

<?xml version1.0«?>

<CustomControl xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance» xmlns:xsdhttp://www.w3.org/2001/XMLSchema«>

<Assembly>Microsoft.ALMRangers.TFSProcTemplateCust.CustomControls.dll</Assembly>

<FullClassName>Microsoft.ALMRangers.TFSProcTemplateCust.CustomControls.CheckBoxControl</FullClassName>

</CustomControl>

Исходный код 21 – Microsoft.ALMRangers.CheckBoxControl.wicc

8. Установите пользовательский элемент управления для Visual Studio

Откройте решение Visual Studio для пользовательского элемента управления (C:\InstallationFolder\CustomControl\Windows\ ALMRangers.CustomControls.slm) и скомпилируйте код.

Скопируйте два файла (Microsoft.ALMRangers.TFSProcTemplateCust.CustomControls.dll и Microsoft.ALMRangers.CheckBoxControl.wicc) в %ProgramData%\Microsoft\Team Foundation\Work Item Tracking\Custom Controls\11.0 под Environment.SpecialFolder.CommonApplicationData (мы также можем использовать каталог под Environment.SpecialFolder.LocalApplicationData) или создайте новое развертывание MSI в Visual Studio (первый путь позволит вам установить элемент управления для всех пользователей для машине, а второй путь установить только для пользователя, который выполняет установку).

9. Загрузите пакет пользовательского элемента управления для Web Access

  • Перейдите на веб-доступ
  • Переключитесь на сайт администрирования
  • В хабе Extensions нажмите «Install New»
  • Выберите архив с пакетом пользовательского элемента управления для загрузки (C:\InstallationFolder\CustomControl\Web Access\Microsoft.ALMRangers.CheckBoxControl.zip)
  • Активируйте расширение

Рисунок 55 – Установленное расширение Web Access

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

Создайте новый рабочий элемент Bug, заметьте, что появилась новая вкладка CustomControl с элементов управления «флажок».

Примечание: Возможно необходимо будет закрыть Visual Studio для последних шагов или нажать обновить в командном обозревателе, чтобы последние изменения были применены, или удалить ваш пользовательский кэш по пути: «c:\user\<username>\AppData\Local\Microsoft\Team Foundation 4.0\cache»

Рисунок 56 – Рабочий элемент с пользовательским элементом управления в Visual Studio

Перейдите в веб-доступ и создайте новый рабочий элемент Bug.

Рисунок 56 – Рабочий элемент с пользовательским элементом управления в Web Access

Примечание

Поскольку это простой элемент управления, то нам нет необходимости иметь какие-либо внешние ресурсы элемента управления (например, библиотеки javascript, изображение или файл CSS), но для более сложных элементов это представляет общую потребность.

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

Примечание

Если вы хотите использовать пользовательские элементы управления, но не хотите разрабатывать их специально для Team Explorer Everywhere, в Team Explorer Everywhere 2012 можно включить функцию для отображения внутри него формы рабочего элемента Web Access вместо родной Java формы.

Это можно включить, выбрав опцию Embedded Work Item Editor в WindowàPreferencesàTeamàTeam Foundation ServeràWork Item Tracking

Рисунок 57 – Выбор внешнего браузера для редактирования рабочих элементов в Team Explorer Everywhere 2012

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

Руководство по настройке шаблона процесса TFS. Сценарий 5 – Клонирование типов рабочих элементов с использованием PowerShell

Posted by Шамрай Александр на Июль 24, 2015

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

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

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

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

  • Обновление существующих командных проектов

Обновление существующих командных проектов

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

1. С помощью приложения Windows PowerShell ISE или Блокнота откройте файл CloneWIT.ps1, который является частью данного руководства.

Рисунок 45 – CloneWIT.ps1 загруженный в Windows PowerShell ISE

ПримечаниеWindows PowerShell Integrated Scripting Environment (ISE) является основным приложением для Windows PowerShell. В Windows PowerShell ISE можно запускать команды, писать, тестировать и отлаживать сценарии в едином Windows ориентированном графическом пользовательском интерфейсе с многострочным редактированием, завершением табуляции, расцветкой синтаксиса, выборочным выполнением, контекстно-зависимой справкой и поддержка языков справа налево. Пункты меню и сочетания клавиш можно использовать для выполнения многих одинаковых задач, которые необходимо выполнить в консоли Windows PowerShell. Например, при отладке сценариев в Windows PowerShell ISE, чтобы задать точку останова в скрипте, щелкните правой кнопкой мыши на строке кода и выберите команду Переключить точку останова.

Дополнительные сведения о приложении Windows PowerShell Integrated Scripting Environment (ISE) можно найти в Интернете.

 

2. Сценарий начинается с загрузки модуля PowerShell, содержащий команды утилиты, которые используются для взаимодействия с Team Foundation Server.

# load the TFS.psm1 PowerShell module located in the same location as this script.

$ScriptDirectory = Split-Path $MyInvocation.MyCommand.Path

Import-Module (Join-Path $ScriptDirectory TFS.psm1)

Исходный код 11 – Модуль загрузки утилит Team Foundation Server

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

function Clone-WorkItemType

{

param (

[psobject] $SourceProject,

[psobject] $DestinationProject,

[string] $WorkItemTypeName,

[Switch] $includeGlobalLists

)

# get the work item type xml from the source project.

$WorkItemType =
$SourceProject.WorkItemTypes[$WorkItemTypeName]

$sourceXml = $WorkItemType.Export($includeGlobalLists)

$definition =
$sourceXml.InnerXml

try

{

# verify against target, may raise an exception

[Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemType]::Validate($DestinationProject, $definition)

# import the work item type definition xml into the dest. project

# if no exceptions, then clone was successful.

$DestinationProject.WorkItemTypes.Import($definition)

Write-Host «Clone succeeded.»

}

catch [System.Xml.XmlException]

{

Write-Error «Xml Exception: \n\n$($_.Message)»

}

catch [System.Xml.Schema.XmlSchemaValidationException]

{

Write-Error «Xml Schema Validation Exception: \n\n$($_.Message)»

}

}

Исходный код 12 – Функция PowerShell Clone-WorkItemType

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

# source and target tfs project collections and team projects

$sourceCollectionName =
«DefaultCollection»

$sourceProjectName =
«PlaygroundAgile50»

$destinationCollectionName =
«DefaultCollection»

$destinationProjectName =
«RangersDemo»

Исходный код 13 – Определение источника и целевого проекта для клонирования

5. По умолчанию при вызове функции Get-Tfs используется имя локального компьютера. Если вы выполняете сценарий CloneWIT.ps1 не на сервере уровня приложений TFS, то вам нужно будет изменить этот параметр на путь к вашему серверу TFS.

# connect to TFS

$tfs = Get-Tfs «http://$env:COMPUTERNAME`:8080/tfs»

Исходный код 14 – Подключение к Team Foundation Server

6. Далее сценарий получает сведения о командных проектах от сервера TFS, используя импортированную команду утилиты Get-TfsCollection.

# create connection to both source and target team projects

$sourceCollection = ($tfs | Get-TfsCollection -Name $sourceCollectionName)

$sourceProject =
$sourceCollection.WIT.Projects[$sourceProjectName]

$destinationCollection = ($tfs | Get-TfsCollection -Name $destinationCollectionName)

$destinationProject = $destinationCollection.WIT.Projects[$destinationProjectName]

Исходный код 15 – Определение источника и целевого проекта для клонирования

7. Затем вызывается функция Clone-WorkItemType с параметрами имени типа рабочего элемента и значением, которое указывает следует ли также копировать глобальные списки. Настройте WorkItemTypeName и includeGlobalLists под ваши потребности.

# call the clone work item type function

Clone-WorkItemType
`

-SourceProject $sourceProject `

-DestinationProject $destinationProject `

-WorkItemTypeName «Bug»

Исходный код 16 – Вызов функции Clone-WorkItemType

8. Сохраните и выполните сценарий, нажав F5 в приложении Windows PowerShell ISE или открыв командную строку и выполнив следующую команду:

powershell.exe -File «C:\HOL\TFS Process Template Customization Guidance\PowerShell\CloneWIT.ps1» false

Исходный код 17 – Выполнение сценария клонирования типа рабочего элемента

ПримечаниеПо умолчанию PowerShell запрещает выполнение сценария на компьютере. Администратор может изменить политику или вы можете добавить параметр -ExecutionPolicy с другим значением такими как Bypass или RemoteSigned.

Дополнительные сведения о политике выполнения PowerShell можно найти, введя

Get-Help about_Execution_Policies

в консоли PowerShell или в PowerShell ISE.

Дополнительные сведения о Windows PowerShell Integrated Scripting Environment (ISE) можно найти в Интернете.

 

9. Сценарий должен завершить со счастливым сообщением; Clone succeeded. Если вы обнаружите ошибку, то она может быть связана с безопасностью или введением неправильных значений в шагах 4, 5 или 7.

Рисунок 46 – Удачное выполнение операции клонирования

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

Руководство по настройке шаблона процесса TFS. Сценарий 4 – Деактивация типа рабочего элемента

Posted by Шамрай Александр на Июль 23, 2015

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

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

Одной из таких причин может быть миграция рабочих элементов в Team Foundation Server (возможно, из другого инструмента), например, для типа рабочего элемента Defect. По той или иной причине в дальнейшем будет использоваться тип Bug внутри Team Foundation Server, и вы хотите предотвратить создание новых рабочих элементов Defect, однако оставаться в состоянии использовать те, что были первоначально мигрированы.

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

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

Настройка

Этот документ представляет два решение для этого сценария из реальной жизни, но с разными результатами:

  • Решение 1 – Создание поля DeactivatedType для рабочего элемента
ПримечаниеС этим решением пользователь не сможет больше создавать новый или изменять существующий рабочий элемент определенного типа.
  • Решение 2 – Деактивация первого перехода для типа рабочего элемента
Примечание
С помощью этого решения пользователь не сможет больше создавать новый рабочий элемент определенного типа, но все еще сможет обновлять существующие рабочие элементов этого типа.

Шаги

Решение 1 – Создание поля DeactivatedType для рабочего элемента

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

Таблица 6 – Решение 1

Решение 2 – Деактивация первого перехода для типа рабочего элемента

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

Таблица 7 – Решение 2

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

Решение 1 – Создание поля DeactivatedType для рабочего элемента

Деактивация выполняется через создание поля DeactivatedType для рабочего элемента с определенными правилами.

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

Чтобы выполнить это, мы можем использовать программу 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:WorkItemTypeName

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


Рисунок 36 – Тип рабочего элемента Defect

3. Создайте поле рабочего элемента DeactivatedType со следующими двумя правилами COPY и PROHIBITEDVALUES

Рисунок 37 – Поле рабочего элемента DeactivatedType

<FIELD name=«Deactivated Type» refname=»Demo.DeactivatedType» type=»String»>

<COPY from=«value» value=»THIS WORK ITEM TYPE HAS BEEN DEACTIVATED» />

<PROHIBITEDVALUES>

<LISTITEM
value=«THIS WORK ITEM TYPE HAS BEEN DEACTIVATED» />

</PROHIBITEDVALUES>

</FIELD>

Исходный код 9 – Поле DeactivatedType

Заметьте, что правило COPY используется запрещенное значение для поля, и пользователь не сможет более создать новый или изменить существующий рабочий элемент этого типа

4. Добавьте поле DeactivatedType на форму рабочего элемента.

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

<Control FieldName=«Demo.DeactivatedType» Type=»FieldControl» ControlFontSize=»large» Label=»[ WARNING ] : » LabelPosition=»Left» ReadOnly=»True» />

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

5. Как раз время протестировать изменения с помощью импорта отредактированного типа рабочего элемента в командный проект. В командной строке Visual Studio:

Вы можете проверить определение XML перед его импортом в командный проект:

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

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

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

6. Теперь попробуйте открыть существующий рабочий элемент. Должно отображаться предупреждение THIS WORK ITEM TYPE HAS BEEN DEACTIVATED. С этого момента существующие рабочие данного типа не будут доступны для редактирования.

Рисунок 39 – Существующий рабочий элемент не может быть изменен

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

Рисунок 40 – Новый рабочий элемент не может больше создан

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

Решение 2 – Деактивация первого перехода для типа рабочего элемента

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

Деактивация реализуется через добавление атрибута not=»[Global]\Project Collection Valid Users» в первый переход секции жизненного цикла типа рабочего элемента.

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

Чтобы выполнить это, мы можем использовать программу 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:WorkItemTypeName

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


Рисунок 41 – Тип рабочего элемента Defect

3. Добавьте следующий атрибут NOT в первую транзакцию в секции жизненного цикла, как указано ниже

Рисунок 42 – Атрибут перехода NOT

4. Как раз время протестировать изменения с помощью импорта отредактированного типа рабочего элемента в командный проект. В командной строке Visual Studio:

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

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

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

Рисунок 43 – Новый рабочий элемент не может быть создан

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

Рисунок 44 – Существующие рабочие элементы могут быть изменены

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

Итог

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

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 »

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

Posted by Шамрай Александр на Декабрь 27, 2014

Шаблон отчета

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

Руководство для шаблона отчета

Форма

Шаблон отчета содержит все элементы формы стандартного отчета TFS:

  1. Описание отчета находится в верхней части и описывает цель отчета.
  2. Ссылки на другие связанные отчеты в правой части для других отчетов в этой категории.
  3. Вопросы, на которые этот отчет помогает ответить.
  4. Значения параметров, используемых для создания отчета. Это полезно, если вы хотите напечатать отчет.
  5. Время обновления данных для определения «свежести» данных в отчете.

Рисунок 9. Форма шаблона отчета

Параметры

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

Ключевые параметры

Это список ключевых параметров, которые необходимы для работы отчета. Их нельзя удалять.

Параметр Использование
ExplicitProject Используется для отладки/тестирования отчета
ReportPath Содержит путь к RDL файлу, что используется потом в dsProjectGuid для получения ProjectGuid
ProjectGuid Содержит Guid проекта
ProjectName Содержит имя проекта
IsDashboard Скрывает все стандартные элементы формы, если установлено как истина, как правило переопределено в URL

Таблица 14. Ключевые параметры

Необязательные параметры

Это список необязательных параметров для поддержки общих сценариев. Удалите их если не будете использовать.

Параметр Использование
IterationParam Содержит выбранную итерацию
AreaParam Содержит выбранную область

Таблица 15. Необязательные параметры

Источники данных

Отчет содержит только один источник данных TFSReports. TFSReports является источником данных для подключения к вашему реляционному TFS хранилищу. Дополнительные сведения о реляционном хранилище TFS и его схеме находятся по адресу http://msdn.microsoft.com/library/bb649552.aspx.

Наборы данных

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

Основные наборы данных

Это список основных наборов данных, необходимых для управления отчетом. Их нельзя удалять.

Набор данных Использование
dsProjectGuid Получает Guid проекта из текущего пути отчета
dsLastProcessedTime Получает время последнего обновления данных

Таблица 16. Ключевые наборы данных

Необязательные наборы данных

Это список необязательных наборов данных.

Набор данных Использование
dsIteration Получает все итерации для командного проекта
dsArea Получает все области для командного проекта

Таблица 17. Необязательные наборы данных

Начало работы

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

Следуйте этим шагам:

Шаг Инструкции
1. Создать новый проект отчета[ ] — Сделано
  • Запустить BIDS (SQL Server Business Intelligence Development Studio).
  • Создать новый Report Server Project с названием MyCustomReport
2. Добавить общий источник данных TfsReportDs[ ] — Сделано
  • В обозревателе решений выбрать правой кнопкой мыши DataSource, Add New Datasource.
  • Назвать его TfsReportDs.
  • Ввести строку подключения и учетные данные для чтения из реляционной базы данных TFS.
3. Добавить и переименовать шаблон[ ] — Сделано
  • В обозревателе решений выбрать правой кнопкой Report, Add existing report.
  • Скопировать и переименовать шаблон отчета ALM рейнджеров в каталог проекта.
  • Выбрать и добавить скопированный отчет.
4. Установить параметр отчета ExplicitProject[ ] — Сделано
  • В обозревателе данных отчета выбрать правой кнопкой мыши ExplicitProject, Parameter Properties.
  • Выбрать вкладку Default Values.
  • Установить в значение по умолчанию путь к существующему командному проекту: /TfsReports/DefaultCollection/TestProject
5. Установить отчет как стартовый для проекта[ ] — Сделано
  • Выбрать правой кнопкой мыши свойства проекта
  • Под элементом Debug/Start item выбрать отчет.
6. Протестировать отчет[ ] — Сделано
  • Нажать F5

Таблица 18. Шаблон отчета – начало работ

Настройка виртуальной машины для использования Analysis Services

Установка Analysis Services в табличном режиме на виртуальной машине Брайана Келлера

Установка SQL Server 2012 Analysis Services

  1. Запустите Виртуальную машину Брайана Келлера и войдите от учетной записи администратора.
  2. Смонтируйте установочный диск SQL Server 2012 или путь к папке с установочным носителем.
  3. Запустите установку.
  4. На странице Product Key нажмите кнопку Next.
  5. Примите условия лицензионного соглашения и нажмите кнопку Next.
  6. Нажмите кнопку Next на странице Product Updates.
    Игнорируйте предупреждение. Мы собираемся установить SP1 позже.
  7. После запуска правил поддержки программы установки, нажмите кнопку Next.
  8. На странице Setup Role выберите SQL Server Feature Installation и нажмите кнопку Next.
  9. На странице выбора компонентов выберите только Analysis Services, Client Tools Connectivity и Client Tools Backwards Compatibility, Management Tools – Basic and Complete и SQL Server Data Tools и нажмите кнопку Next.
    Обратите внимание, что в этом случае мы не будем пытаться устанавливать PowerView. Это более сложный процесс, так что давайте не будем беспокоиться об этом прямо сейчас.
  10. После запуска правил установки, нажмите кнопку Next.
  11. Instance Configuration должен быть именованный экземпляр, так что назовем его «Tabular» и нажмите кнопку Next.
  12. В disk space requirements нажмите кнопку Next.
  13. В разделе server configuration нажмите кнопку Next.
  14. На странице Analysis Services Configuration выберите Tabular Mode (по умолчанию используется Multidimensional and Data Mining Mode).
  15. Нажмите кнопку Add Current User и нажмите кнопку Next (можете добавить других пользователей, но не обязательно).
  16. На странице Error Reporting нажмите кнопку Next.
  17. После выполнения правил настройки установки, нажмите кнопку Next.
  18. На странице готовности для установки нажмите Install.
  19. После завершения установки нажмите кнопку Close.

Установка SQL Server 2012 x64 SP1

  1. Вставьте диск SQL Server 2012 в виртуальной машине и запустите установку x64 SP1.

Проверка установки

  1. Для проверки установки откройте SQL Server Management Server 2012, подключитесь к localhost\tabular и проверьте свойства.

Понимание модели реляционных данных хранилища рабочих элементов

Каждый новый экземпляр Team Foundation Server создает следующие базы данных на сервере данных:

  • Tfs_Configuration
  • Tfs_DefaultCollection (или Tfs_ <CollectionName> если ваша командная коллекция имеет другое имя)
  • Tfs_Warehouse
  • Tfs_Analysis

Первые три базы данных – это OLTP баз данных, созданные в службе баз данных SQL Server. Tfs_Analysis является OLAP базой данных, созданной службой анализа SQL Server. В следующей таблице приведено краткое описание каждой базы данных:

Имя базы данных Тип Описание
Tfs_Configuration Реляционная база данных Эта база данных хранит каталог ресурсов и конфигурации сервера Team Foundation Server. Каждая установка TFS имеет только одну базу данных Tfs_Configuration.
Tfs_<CollectionName> Реляционная база данных Для каждой новой командной коллекции создается новая базы данных Tfs_ <CollectionName>. Эта база данных содержит фактические данные командных проектов в командной коллекции. Это хранилище первичных данных, которые записываются при создании новых рабочих элементов или поставке под контроль файлов.
Tfs_Warehouse Реляционная база данных Tfs_Warehouse реляционная база данных хранилища TFS и предоставляет данные в формате, который упрощает отчетность.
Tfs_Analysis OLAP куб Базы данных Tfs_Analysis является многомерным кубом OLAP, который содержит агрегированные данные team foundation server.

Таблица 19. Базы данных сервера данных TFS

Майкрософт рекомендует использовать базы данных Tfs_Warehouse и Tfs_Analysis для отчетности. О структуре и схеме этих баз данных существует достаточно документации. Однако каналы данных Tfs_Warehouse обновляются каждые два часа и формат может быть нежелателен при определенных обстоятельствах. Все базы данных командных коллекций сходятся в эти базы данных (Tfs_Warehouse и Tfs_Analysis).

В этом разделе описывается схема Tfs_DefaultCollection для поддержки пользователей, которые хотят использовать данные из базы данных OLTP для отчетности.

Предупреждение Майкрософт не рекомендует использовать эту базу данных для отчетности по следующим причинам:

  • Схема базы данных Tfs_DefaultCollection может изменяться в будущих версиях или при обновлении сервера TFS.
  • Запросы непосредственно к базе данных могут иметь неблагоприятное воздействие на производительность вашего сервера TFS. Поэтому рекомендуется использовать locking hint, чтобы ваши запросы не блокировали базу данных.
  • Любые случайные изменения в данных этой базы данных может повредить ваш сервер TSF. Данные в этой базе данных не должны изменяться. Всегда подключайтесь к этой базе данных пользователем, который имеет доступ только для чтения.

 

Чтобы обеспечить рекомендации от Microsoft, при создании нового командного проекта (значение по умолчанию — службы Reporting Services), мы должны подключаться только к источникам данных из баз данных Tfs_Warehouse (названный TFSReportsDS) и Tfs_Analysis (названный TFSOlapReportsDS). В этом документе мы подробно рассмотрим, как данные по рабочим элементам хранятся в базе данных Team Foundation Server.

Таблицы Tfs_DefaultCollection

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

[dbo].[WorkItemsAre]

Эта таблица является первичной таблицей, которая содержит все рабочие элементы. Таблица содержит следующие столбцы:

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[Changed Date] Дата и время последнего изменения рабочего элемента
[PersonId] ID персоны, которая создала рабочий элемент
[AreaID] ID области, к которой принадлежит рабочий элемент. Это поле содержит внешний ключ к таблице [xxTree]
[Rev] Номер версии рабочего элемента. При каждом обновлении значение поля увеличивается на 1.
[State] Текстовое поле состояния рабочего элемента
[Reason] Текстовое поле причины рабочего элемента
[Assigned To] ID пользователя, на которого назначен рабочий элемент.
[Created By] ID пользователя, который создал рабочий элемент.
[ID] ID рабочего элемента.
[Changed Order] Поле отметки времени для записи
[Authorized Date] Дата и время последнего обновления рабочего элемента
[Created Date] Дата и время создания рабочего элемента
[IterationID] ID выбранной итерации рабочего элемента. Это поле содержит внешний ключ к таблице [xxTree]
[Title] Текстовое поле названия рабочего элемента
[Changed By] ID пользователя, который последним изменил рабочий элемент.
[Work Item Type] Текстовое поле типа рабочего элемента

Таблица 20. Таблица [dbo].[WorkItemsAre]

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

Например, следующая таблица возвращает имя и значение из поля fld10002 для всех рабочих элементов:

SELECT WorkItems.ID, Fields.Name as FieldName, WorkItems.Fld10002 as FieldValue FROM [WorkItemsAre] WorkItems LEFT JOIN [Fields] ON Fields.FldID = 10002

[dbo].[WorkItemsLatest]

Таблица [dbo].[WorkItemsLatest] имеет ту же схему, что и таблица [dbo].[WorkItemsAre], за исключением того, что он содержит дополнительное поле под названием «Revised Date». Эта таблица может использоваться взаимозаменяемо с таблицей [dbo].[WorkItemsAre].

[dbo].[WorkItemsWere]

Таблица [dbo].[WorkItemsWere] содержит исторические данные таблицы [dbo].[WorkItemsAre]. Она имеет ту же схему, что и таблица [dbo].[WorkItemsAre]. При каждом изменении рабочего элемента создается новая запись в этой таблице. Новая запись содержит состояние рабочего элемента до изменения.

[dbo].[WorkItemLongTexts]

Html поля рабочих элементов хранятся в отдельной таблице, называемой [dbo].[WorkItemLongTexts]. Каждый раз, когда обновляется поле html, создается новая запись в этой таблице. Однако эта таблица записывается только тогда, когда есть изменения в поле html. Это означает, что не все номера версии установленные в таблице [dbo].[WorkItemsWere] будут иметь соответствующую запись в этой таблице. Схема таблицы представлена подробно здесь:

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[AddedDate] Дата добавления значения html поля
[FldID] ID персоны, которая создала рабочий элемент
[ID] ID рабочего элемента для этого поля html.
[Words] Текст поля html.
[Changed Order] Поле отметки времени для записи
[Rev] Номер версии рабочего элемента, в которой было сделано изменение html поля.
[fHtml] Логическое поле, которое показывает, что данное поле html.
[IndexedWords] Бинарное поле, которое содержит хеш-код поля Words.
[WordsDocumentType] Текстовое поле, которое содержит тип данных хранящихся в поле. Возможные значения .txt, .html
[TextID] Это поле идентификационных данных и первичный ключ таблицы.
[EndDate] End Date заполняется только для записей, которые не являются в настоящее время активными. То есть поле было обновлено и создается новая запись с новыми значениями. Для каждого обновления поля для текущей записи заполняется поле EndDate и создается новая запись.

Таблица 21. Таблица [dbo].[WorkItemsLongTexts]

[dbo].[WorkItemFiles]

Таблица [dbo].[WorkItemFiles] содержит информацию о всех файлах, прикрепленных к рабочему элементу. В следующей таблице приведена схема таблицы [dbo].[WorkItemFiles]:

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[RemovedDate] Дата и время удаления вложения из рабочего элемента. Заполняется только для удаленных вложений.
[AddedDate] Дата и время добавления вложения к рабочему элементу
[FldID] ID поля рабочего элемента, которое хранит прикрепленный файл
[ID] ID рабочего элемента, к которому прикреплен файл.
[FilePath] Поле заполняется с GUID из поля FileGuid в таблице [dbo].[Attachment], где хранится содержимое файла.
[ExtID] Это поле идентификационных данных и первичный ключ таблицы.
[Comment] Текстовое поле, которое содержит комментарий, написанный пользователем при вложении файла.
[CreationDate] Дата и время создания файла во вложении.
[LastWriteDate] Дата и время последнего изменения файла во вложении.
[Length] Размер файла в байтах.
[Historical Added Date] Дата и время сохранения рабочего элемента, когда было давлено вложение.
[Historical Removed Date] Дата и время сохранения рабочего элемента, когда было удалено вложение.

Таблица 22. Таблица [dbo].[WorkItemsFiles]

[dbo].[LinksAre]

Таблица [dbo].[LinksAre] содержит информацию об одной или нескольких связей.

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[SourceID] ID рабочего элемента, из которого создана связь
[TargetID] ID рабочего элемента, к которому создана связь
[LinkType] Link Type ID для связи. Это поле является внешним ключом, ссылающимся на таблицу [dbo].[LinkTypes], которая содержит информацию о различных типах ссылок, которые могут быть созданы между двумя рабочими элементами.
[ReverseLinkType] Link Type ID для ссылки из целевого рабочего элемента на исходный рабочий элемент. Это поле является внешним ключом, ссылающимся на таблицу [dbo].[LinkTypes], которая содержит информацию о различных типах ссылок, которые могут быть созданы между двумя рабочими элементами.
[Created By] ID пользователя, который создал ссылку.
[Created Date] Дата и время создания ссылки.
[Comment] Текстовое поле, которое содержит комментарий, написанный пользователем при создании ссылки.
[Historical Added Date] Дата и время сохранения рабочего элемента, когда была давлена связь.

Таблица 23. Таблица [dbo].[LinksAre]

[dbo].[LinksWere]

Похоже на таблицу [dbo].[WorkItemsWere], [dbo].[LinksWere] содержит историческую информацию о связях между рабочими элементами. Когда связь между рабочими элементами отредактирована или удалена, создается новая строка в таблице [dbo].[LinksWere] считывая информацию неизмененной ссылки из таблицы [dbo].[LinksAre] перед записью в таблицу [dbo].[LinksAre] при редактировании или удалении.

[dbo].[WorkItemsDestroyed]

Таблица [dbo].[WorkItemsDestroyed] содержит список удаленных рабочих элементов. Когда рабочий элемент удаляется, его данные удаляются из таблиц [dbo].[WorkItemsAre] и [dbo].[WorkItemsWere] и создается новая запись в таблице [dbo].[WorkItemsDestroyed].

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[ID] ID удаленного рабочего элемента.
[Changed Order] Поле отметки времени для записи
[Changer ID] ID пользователя, который удалил рабочий элемент.

Таблица 24. Таблица [dbo].[WorkItemsDestroyed]

[dbo].[WorkItemLinksDestroyed]

Когда рабочий элемент связан с другими рабочими элементами и источник или целевой объект удаляется, создается запись в таблице [dbo].[WorkItemLinksDestroyed]. Таблица имеет следующую схему.

Название поля Описание
[PartitionId] Столбец может использоваться для разделения таблицы. Если разделение не сконфигурировано, он всегда заполняется со значением 1.
[SourceID] ID рабочего элемента, из которого создана связь
[TargetID] ID рабочего элемента, к которому создана связь
[LinkType] Текстовое поле, которое содержит описание типа ссылки, которая была удалена.
[ChangeDate] Дата, когда ссылка была удалена
[DeletedTimeStamp] Отметка времени записи оригинальной ссылки, которая была удалена.
[TimeStamp] Отметка времени записи.

Таблица 25. Таблица [dbo].[WorkItemLinksDestroyed]

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

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