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

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

Posts Tagged ‘reporting’

Отчет по возрасту ошибок в TFS

Posted by Шамрай Александр на Апрель 3, 2017

«Борьба» с техническим долгом команды является неотъемлемой частью любого процесса разработки. Команда всегда старается минимизировать количество существующих проблем, но зачастую для нового релиза устанавливаются пороги качества, которым он должен соответствовать, и в него входит пограничное количество ошибок определенной важности. Пороги могут варьировать в зависимости от сложности проекта, а иногда приходится выпускать релиз с превышением установленных порогов, находясь под давлением различных обстоятельств (дедлайны, требования заказчика или прямого руководства). В случае если выпущенный релиз содержит ошибки с высокой важностью, то команда старается описать ее как «известную проблему» и в ближайшее время старается ее решить. TFS обеспечивает необходимые отчеты, которые позволяют акцентировать внимание на текущие проблемы качества и их тренды. Но, к сожалению, нет отчетов, которые бы показали насколько старыми являются наши ошибки или насколько долго они находятся в определенном состоянии. Такие отчеты позволяют шире посмотреть на существующие ошибки:

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

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

  1. Поле для отслеживания изменения состояния. Это поле «Microsoft.VSTS.Common.StateChangeDate», которое обновляется при изменении состоянии соответствующей датой. Для того, чтобы оно попадало в отчетную базу, ему нужно установить атрибут Reportable в значение dimension. Для этого мы воспользуемся TFS Power Tools. На скриншотах ниже отображена последовательность шагов для обновления. После изменения атрибута сохраняем результаты работы.

Рисунок 1. Изменение свойства отчетности для поля

  1. Шаблон отчета. ALM Ranger-ы выпустили Руководство по отчетности TFS, которое было переведено в рамках данного блога. Данное руководство содержит предварительно подготовленный шаблон отчета на английском языке. Тут можно получить шаблон на русском языке. Шаблон отчета открываем в Report Builder и сохраняем в необходимом каталоге проекта на сервере отчетности.
  2. Параметры отчета. Для отчета можно установить параметры, которые позволят сузить количество выдаваемой информации, например, по состояниям. Для этого мы добавим новый параметр, установим для него возможные значения, установим значение по умолчанию.

Рисунок 2. Добавление нового параметра

Рисунок 3. Список выбора для параметра

  1. Набор данных отчета. Набор данных включает в себя запрос, который должен отобрать необходимые ошибки согласно заданным параметрам и при этом установить соответствующий атрибут его возраста. В рамках данного запроса устанавливаются атрибуты 1 неделя, 2 недели, 3 недели, 4 недели и более. Пример запроса:
SELECT

CurrentWorkItemView.System_Id

,CurrentWorkItemView.System_Title

,CurrentWorkItemView.System_State

,CurrentWorkItemView.System_AssignedTo

,CurrentWorkItemView.Microsoft_VSTS_Common_Priority

,CurrentWorkItemView.Microsoft_VSTS_Common_Severity

,CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate

,CurrentWorkItemView.System_CreatedDate

,CASE WHEN (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())>0) AND (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())<8) THEN 1 ELSE 0 END One_Week

,CASE WHEN (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())>7) AND (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())<15) THEN 1 ELSE 0 END Two_Weeks

,CASE WHEN (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())>14) AND (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())<22) THEN 1 ELSE 0 END Three_Weeks

,CASE WHEN (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())>21) AND (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())<29) THEN 1 ELSE 0 END Four_Weeks

,CASE WHEN (DATEDIFF(day, CurrentWorkItemView.Microsoft_VSTS_Common_StateChangeDate, GETDATE())>28) THEN 1 ELSE 0 END Very_Old

FROM

CurrentWorkItemView

WHERE

CurrentWorkItemView.System_WorkItemType = N’Ошибка’

AND CurrentWorkItemView.System_State IN (@State)

AND CurrentWorkItemView.ProjectNodeGUID = @ProjectGuid

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

Рисунок 4. Выбор набора данных для диаграммы

Рисунок 5. Тип диаграммы

Рисунок 6. Выбор полей для диаграммы

Рисунок 7. Стиль диаграммы

  1. Отчет готов. Можно оценить его результат.

Рисунок 8. Отчет «Возраст ошибок»

Готовый отчет можно скачать здесь.

Реклама

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

Отчет о списывании времени с задач

Posted by Шамрай Александр на Март 28, 2015

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

Выполнять разработку отчета с чистого листа нет смыслы, т.к. есть возможность взять за основу отчеты, которые поставляются с TFS. Немного «почистив» стандартный отчет, можно получить типовой шаблон для всех последующих отчетов. Пример такого отчета можно скачать как zip-архив здесь. Данный отчет можно редактировать с помощью Report Builder. Отчет содержит некоторые параметры, которые динамически определяют название проекта, поэтому для того, чтоб он заработал его необходимо открыть и сохранить на Report Server в каталог необходимого командного проекта:

Рисунок 1. Сохранение отчета на сервере отчетности

Кроме этого необходимо убедитmся, что источник данных указывается на правильное соединение TFSReportDS:

Рисунок 2. Свойства источника данных

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

Рисунок 3. Свойства источника данных

Текст запроса можно использовать ниже приведенный, он взят из руководства по отчетности от ALM Rangers. Этот запрос отбирает из таблицы WorkItemHistoryView необходимые данные, а также стразу подчитывает разницу времени, которe. исполнитель указал в рабочем элементе.

SELECT

[System_Id] As [Id],[System_Rev] As [Rev],

[System_ChangedBy] As [Changed By],

[Microsoft_VSTS_Scheduling_OriginalEstimate] AS [Original Estimate],

[Microsoft_VSTS_Scheduling_RemainingWork] AS [Remaining Work],

[Microsoft_VSTS_Scheduling_CompletedWork] AS [Completed Work],

[System_Title] As [Title],[System_AssignedTo] As [Assigned To],

[System_ChangedDate] As [Changed Date],

[ProjectNodeName] AS [Team Project],

[AreaName],[AreaPath],

[IterationName],

[IterationPath],

[Microsoft_VSTS_Scheduling_RemainingWork] — (Select Top 1 IsNull([Microsoft_VSTS_Scheduling_CompletedWork],0)

FROM [Tfs_Warehouse].[dbo].[WorkItemHistoryView] WITH(NOLOCK)

WHERE [System_Id] = WIHV.[System_Id]

AND [System_Rev] = WIHV.[System_Rev] — 1) as [Completed Diff]

FROM

[Tfs_Warehouse].[dbo].[WorkItemHistoryView] WIHV WITH(NOLOCK)

WHERE

/** Filter team project **/

[ProjectNodeName] LIKE @ProjectName

/** Filter correction entries **/

AND [RevisionCount] IS NOT NULL /** Filter empty entries **/

AND ([Microsoft_VSTS_Scheduling_OriginalEstimate] IS NOT NULL

OR [Microsoft_VSTS_Scheduling_RemainingWork] IS NOT NULL

OR [Microsoft_VSTS_Scheduling_CompletedWork] IS NOT NULL)

ORDER BY ID, Rev

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

Рисунок 4. Вставка таблицы результатов мастером

Далее в новую таблицу мы добавляем поля, которые нам необходимы для отображения:

Рисунок 5. Добавление новых полей

И теперь мы уже можем проверить результат, нажав кнопку Выполнить в Report Builder. Но на текущий момент отчет будет отбирать все изменения, которые были выполнены в TFS. Нам же необходимо отобрать по конкретной дате. Для этого нам нужно добавить новый параметр в отчет и вставить его в тело запроса для нашего набора данных. Добавить параметр можно в соответствующем разделе отчета и указав следующие свойства:

Рисунок 6. Свойства параметра

Теперь сталось добавить данный параметр в тело запроса, где мы будем сравнивать задаваемую дату с датой изменения рабочего элемента. При этом нужно помнить, что данный параметр и значение поля рабочего элемента имеют тип Дата-Время, поэтому мы приведем их только к дате. Пример запроса в наборе данных ниже:

Рисунок 7. Измененный запрос

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

Рисунок 8. Готовый отчет

Дополнительные ссылки:

Posted in Microsoft, Team Foundation Server, 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 »

Практическое руководство по отчетности TFS. Адаптеры данных и Хранилище TFS

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

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

 

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

Рисунок 9. Архитектура Хранилища данных

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

Основы разработки адаптеров хранилища TFS

Реализация адаптера

Реализуются два интерфейса, когда вы получаете данные из операционных таблиц и вставляете их в хранилище данных TFS: IWarehouseAdapter и IDataStore. Интерфейс IWarehouse используется службой хранилища данных TFS для вызова пяти основных адаптеров по определенному графику для изменения данных. Интерфейс IDataStore используется службой хранилища данных TFS для взаимодействия в хранилище данных TFS.

IWarehouseAdapter имеет четыре метода:

  • Initialize: создает объекты, которые взаимодействуют с операционным хранилищем и хранилищем данных.
  • MakeSchemaChanges: создает новый атрибут измерения в хранилище. Этот атрибут содержит описание политики переопределения.
  • MakeDataChanges: вызывается каждый раз, когда вы обновляете хранилище. В этом адаптере метод проверяет все наборы изменений, сделанные с времени последнего обновления хранилища. Если набор изменений содержит описание переопределения политики, он вызывает метод SavePolicyOverrideCommentDimAttribute, который сохраняет описание в хранилище.
  • Cancel: когда вы хотите остановить адаптер.

Используя пример CSharp Assembly Churn, который предоставляется Microsoft, вы увидите лучшие практики создания отдельного таблицы измерения для данных, которые требуется добавить в хранилище данных TFS. Вам нужно иметь в виду, что версии TFS разные и вам не нужно быть привязанным к их таблицам, так как нет никакой гарантии, что они будут такими же после применения накопительного обновления или обновления версии.

Этот пример содержит SQL и классы, используемые при создании таблиц измерений, фактов и хранимых процедур, используемых в хранилище данных TFS и SQL.

Реализация с использованием адаптера для внесения данных изменений находится в классе CSharpAssemblyCodeChurnSampleAdapter. Этот класс содержит метод ProcessChangesets, который используется для получения сведений о сборке для файлов и их добавления в хранилище данных TFS.

Развертывание адаптера

Хорошим подходом является тестирование развертывания в непроизводственной среде. Можно рассмотреть использование виртуальной машины Брайана Келлера, если у вас только одна среда.

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

  • Скопируйте сборку в папку plugins хранилища
    • «C:\Program Files\Microsoft Team Foundation Server 11.0\Application Tier\Web Services\bin\Plugins» для TFS 2012
    • «C:\Program Files\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\bin\Plugins» для TFS 2013
  • Перезапустите IIS.
  • Откройте браузер и перейдите по адресу https://localhost/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx?op=GetProcessingStatus и нажмите кнопку Invoke.
  • Продолжайте делать это до тех пор, пока статус возвращается как Idle.
  • Убедитесь, что это не вызвало никаких проблем, проверив журнал событий приложений Windows на отсутствие каких-либо ошибок.

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

Рекомендуется выполнять мониторинг состояния обработки хранилища данных TFS. Отчеты о состоянии обработки куба Гранта Холлидея обеспечат информацию об ошибках, которые возникают.

Важная информация

Элементы, на которые стоит обратить внимание:

  • Важные изменения схемы в структуре таблицы хранилища:
    • TFS 2010: до сих пор используется много внешних ключей каскадного удаления, что убивает производительности
    • TFS 2010 SP1: удалено большинство связей с внешними ключами, адаптерам необходимо «очищать после себя»
    • TFS 2012/2013: едва ли были какие-либо изменения в хранилище данных, но схема операционного хранилища была значительно изменена, особенно в области сборок
  • Версии платформы .NET framework, параметры ЦП для адаптеров
    • TFS 2010: .NET 4, AnyCPU, с ожидаемой загрузкой в среде x64
    • TFS 2012: .NET 4.5, AnyCPU, с ожидаемой загрузкой в среде x64
    • TFS 2013: .NET 4.5.1, AnyCPU, с ожидаемой загрузкой в среде x64
  • Минимальные требования SQL Server
    • TFS 2010 (SQL Server 2008)
    • TFS 2012 (SQL Server 2008 R2)
    • TFS 2013 (SQL Server 2012)
    • SQL 2014 не был проверен
  • Сборки для ссылки и где их найти
    • Описания SK/BK для существующих измерений и фактов
    • Отладка адаптера (присоединить Visual Studio к службе TFS Job)
    • Срабатывание адаптера (вызов веб-службы хранилища)

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

Практическое руководство по отчетности TFS. Дополнительный Сервис Отчетности

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

Для каждой коллекции проектов Team Foundation Server создает базу данных OLTP. База данных для коллекции командных проектов по умолчанию называется Tfs_DefaultCollection. Здесь TFS хранит все «активные» данные. Данные из этой базы данных подаются сначала в базу данных звездообразной схемы Tfs_Warehouse, а затем к OLAP кубу Tfs_Analysis.

Т.к. создание отчетов поддерживается из баз данных Tfs_Warehouse и Tfs_Analysis, Microsoft не рекомендует создавать отчеты напрямую из базы данных Tfs_DefaultCollection. Причина этого в том, что схема база данных OLTP часто меняется новыми TFS релизами и обновлениями.

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

Это руководство поставляется с примером службы WCF. Служба использует TFS API для получения информации о сборках и шагах сборки из базы данных OLTP.

Предварительные требования

Чтобы настроить дополнительный сервис отчетности, вам понадобится машина со следующими возможности Microsoft Windows:

  • Microsoft Internet Information Server (IIS) v 7.0 or v. 8.0.
  • Microsoft .NET Framework 4.

Требования к безопасности

Вам нужно будет иметь учетную запись службы, которая добавлена в группу TFS «Builders». Группа Builders создается для каждой вновь созданной коллекции командных проектов.

Пошаговое руководство

Шаг Инструкции
1 Установка

[ ] — Сделано

  • Скопируйте папку Teamreports\TeamReportService из кода примера на веб-сервер, где вы будете развертывать дополнительную службу TFS. Вы можете использовать сервер приложений TFS или какую-то другую машину, которая может вызывать TFS API.
  • Откройте службы IIS и создайте пул приложений, который называется TFSReports.
  • Выберите .Net Framework v4.0.30319 для версии .NET Framework и Integrated для режима управляемого конвейера.
  • Нажмите кнопку ОК, чтобы создать пул приложений. Щелкните на нем правой кнопкой мыши и выберите пункт Advanced Settings.
  • Нажмите Identity и задайте учетную запись для службы, как указано в требовании безопасности выше.
  • Создайте новый веб-сайт с называнием TfsReports. Выберите свой недавно созданный пул приложений TFSReports как пул приложений и установите сайт на скопированный каталог TeamReportsService.
  • Для привязки созданного веб-сайта задайте ему уникальное имя DNS или назначьте уникальный порт на сервере. Нажмите кнопку ОК. Служба в настоящее время развернута и готова к вызову.
2. Понимание Сигнатуры

[ ] — Сделано

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

/// <summary>

///
Returns the Build Step Duration report for a given build

/// </summary>

/// <param name=»projectCollectionUri»>The Project collection Uri</param>

/// <param name=»teamProjectName»>The Team Project Name</param>

/// <param name=»buildDefinitionName»>The build definition name for the build for which the report should return the build duration. Only the latest build is extracted.</param>

///<param name=»reportOption»>An enumeration that determines which steps should be returned</param>

/// <returns>A list of build steps with their respective duration</returns>

[OperationContract]

IEnumerable<BuildStep> GetBuildStepDurationReport(string projectCollectionUri, string teamProjectName, string buildDefinitionName, BuildStepDurationReportOption reportOption);

  • Он принимает идентификатор сборки в качестве параметра и возвращает список всех сборок.
3. Понимание Операций

[ ] — Сделано

  • Операция принимает такие параметры, как URL-адрес коллекции командного проекта, имя командного проекта, имя определения сборки и перечисление, которое позволяет вызывающему объекту указать нужны ли все шаги, десять самых быстрых или десять самых медленных шагов.
  • Результатом является перечисление объектов BuildStep, который содержит свойства такие как имя шага сборки, время начала, время окончания и продолжительность.

/// <summary>

/// The BuildStep class encapsulates a single Build Step in a build report

/// </summary>

[DataContract]

public class BuildStep

{

/// <summary>

/// Gets or sets the name of the Build Step

/// </summary>

[DataMember]

public string Name { get; set; }

/// <summary>

///
Gets or sets the Start Time of the Build Step

/// </summary>

[DataMember]

public DateTime StartTime { get; set; }

/// <summary>

///
Gets or sets the End Time of the Build Step

/// </summary>

[DataMember]

public DateTime? EndTime { get; set; }

/// <summary>

///
Gets or sets the Duration of the build Step

/// </summary>

[DataMember]

public TimeSpan? Duration { get; set; }

}

  • Операция возвращает список шагов с их продолжительность выполнения в последней сборке…
  • Отчет полезен для менеджеров сборки, которые хотят диагностировать, какие наиболее медленные части.
4. Создание Клиентского Прокси-приложения

[ ] — Сделано

  • Использование службы можно продемонстрировать с помощью приложения WcfTestClient.exe, которое входит в состав Visual Studio. Для создания клиента выполните следующие действия:
  • Создайте новое консольное приложение Windows в Visual Studio.
  • Щелкните правой кнопкой мыши на ссылки служб и нажмите Add Service Reference.
  • В URL-адрес службы введите http://TFSCustomReports/BuildService.svc и нажмите кнопку Go. Выберите BuildReports, введите название подходящего пространства имен и нажмите кнопку ОК.

  • Нажмите кнопку ОК. Это сгенерирует прокси-класс для службы.
5. Клиентский Код

[ ] — Сделано

  • Теперь создайте экземпляр прокси-класса и выполните его вызов.
  • Окончательный код выглядит так:

    using (var client = new BuildReportsClient())

    {


    var buildSteps = client.GetBuildStepDurationReport( «*TeamProjectCollectionUri», «TeamProjectName», «BuildDefinitionName», BuildStepDurationReportOption.All);


    foreach (var step in buildSteps)

    {

    Console.WriteLine(«Build Step {0} — Duration {1}», step.Name, step.Duration);

    }

    }

6. Запуск Клиента

[ ] — Сделано

  • Перестройте и запустите клиентское приложение, нажав клавишу F5.

Таблица 13. Пошаговое руководство для дополнительного сервиса отчетности

Примечание Пример службы и клиента включен в код этого руководства.https://vsarreportguide.codeplex.com/releases/view/115743

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

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

Posted by Шамрай Александр на Май 16, 2014

Отчет «Длительность сборки»

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

Таблица 3. Отчет «Длительность сборки»

Рисунок 2. Отчет «Длительность сборки»

Предварительные требования

  • Пользователю необходим доступ к базе данных TFS_<Название коллекции>, где <Название коллекции> имя командной коллекции.

Пример

TFS 2010

Следующий код работает для TFS 2010. В этом примере мы устанавливаем @BuildId как последнюю сборку. Если вы хотите получить результат для конкретной сборки, то вам необходимо будет установить значение идентификатора сборки.

  • Tbl_build – таблица содержит запись для каждой сборки.
  • Tbl_InformationType – таблица хранит информацию каждого шага, который выполняется как часть командной сборки.
  • Tbl_buildInformation – таблица с информацией о сборке, которая хранит детальную информацию о результате выполнения каждого шага, указанную в виде информационного типа сборки, для каждой сборки. Схема таблицы отличается у TFS 2010 и TFS2012. В TFS2012 таблица хранит информацию в столбце с именованными полями, в то время как в TFS2010 информация хранятся в отдельной таблице, называемой tbl_BuildInformationFields.
  • Tbl_buildInformationFields – таблица содержит информационные поля для каждой строки tbl_BuildInformation для каждой сборки. Количество полей зависит от BuildInformationType.

 

Код 1.
Отчет «Длительность сборки» для TFS 2010

DECLARE @BuildId int;

— Using this SELECT as just an example to get the latest build to view the details of

SELECT @BuildId = MAX(BuildId) FROM tbl_BuildInformation bi WITH(NOLOCK);

 

SELECT bi.NodeId

,bi.ParentId

,bity.TypeName

,bi.LastModifiedDate

,dpt.FieldValue DisplayText

,CONVERT(DATETIME2, st.FieldValue) StartTime

,CONVERT(DATETIME2, ft.FieldValue) FinishTime

,DATEDIFF(SECOND, st.FieldValue, ft.FieldValue) AS Duration (Seconds)

,CAST((DATEDIFF(SECOND, st.FieldValue, ft.FieldValue))/60.0 AS DECIMAL (12,2)) AS Duration (Minutes)

,sp.FieldValue ServerPath

FROM tbl_BuildInformation bi WITH(NOLOCK)

INNER JOIN tbl_BuildInformationType bity on bi.NodeType = bity.NodeType

LEFT OUTER JOIN (SELECT NodeId,

FieldValue

FROM tbl_BuildInformationField WITH(NOLOCK)

WHERE FieldName = ‘DisplayText‘) dpt ON bi.NodeId = dpt.NodeId

LEFT OUTER JOIN (SELECT NodeId,

FieldValue

FROM tbl_BuildInformationField WITH(NOLOCK)

WHERE FieldName = ‘StartTime‘) st ON bi.NodeId = st.NodeId

LEFT OUTER JOIN (SELECT NodeId,

FieldValue

FROM tbl_BuildInformationField WITH(NOLOCK)

WHERE FieldName = ‘FinishTime‘) ft ON bi.NodeId = ft.NodeId

LEFT OUTER JOIN (SELECT NodeId,

FieldValue

FROM tbl_BuildInformationField WITH(NOLOCK)

WHERE FieldName = ‘ServerPath‘) sp ON bi.NodeId = sp.NodeId

WHERE BuildId = @BuildId

AND bity.TypeName NOT IN (‘BuildMessage‘,

BuildWarning‘,

ExternalLink‘,

ConfigurationSummary‘)

ORDER BY NodeId;

TFS 2012

Схема базы данных TFS 2010 отличается от TFS2012 и tbl_BuildInformation таблицы больше не существует. Поэтому упомянутый выше запрос не будет работать в TFS2012. Альтернативный подход заключается в использовании API в Team Foundation Server, в использовании доступного интерфейса и получении отчета через настроенную службу. В этом случае я создал WCF службу со следующим интерфейсом.

Код 2.
Интерфейс IBuildReports для отчета «Длительность сборки» для TFS 2012

/// <summary>

/// The IBuildReports service interface provide methods for a the various build reports

/// created from Team Foundation Server’s service

/// </summary>

[ServiceContract]

public interface IBuildReports

{

/// <summary>

/// Returns the Build Step Duration report for a given build

/// </summary>

/// <param name=»projectCollectionUri»>The Project collection Uri</param>

/// <param name=»teamProjectName»>The Team Project Name</param>

/// <param name=»buildDefinitionName»>The build definition name for the build for which the report should return the build duration. Only the latest build is extracted.</param>

/// <param name=»reportOption»>An enumeration that determines which steps should be returned</param>

/// <returns>A list of build steps with their respective duration</returns>

[OperationContract]

IEnumerable<BuildStep> GetBuildStepDurationReport(string projectCollectionUri, string teamProjectName, string buildDefinitionName, BuildStepDurationReportOption reportOption);

}

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

Параметр Описание
projectCollectionUri URI подключения коллекции командного проекта.
teamProjectName Имя командного проекта, который содержит сборку.
buildDefinitionName Имя определения сборки.
reportOptions Перечисление возможно со следующими опциями:

  • All – возвращает все шаги сборки
  • SlowestTen – возвращает 10 самых продолжительных сборки
  • FastestTen – возвращает 10 самых быстрых сборки.

Таблица 4.
Параметры отчета «Длительность сборки» для TFS 2012

Тип возвращаемого значения является перечисление объектов типа «BuildStep», которое содержит сведения о каждом шаге сборки и времени его выполнения. Тип Шаг Сборки выглядит следующим образом:

Код 3.
Отчет «Длительность сборки» для TFS 2012 тип BuildStep

[DataContract]

public class BuildStep

{

/// <summary>

/// Gets or sets the name of the Build Step

/// </summary>

[DataMember]

public string Name { get; set; }

/// <summary>

/// Gets or sets the Start Time of the Build Step

/// </summary>

[DataMember]

public DateTime StartTime { get; set; }

/// <summary>

/// Gets or sets the End Time of the Build Step

/// </summary>

[DataMember]

public DateTime? EndTime { get; set; }

/// <summary>

/// Gets or sets the Duration of the build Step

/// </summary>

[DataMember]

public TimeSpan? Duration { get; set; }

}

Реализация IBuildReports показана ниже:

/// <summary>

/// The BuildReports class provides functionality for all Build Reports created from Team Foundation

/// Server’s service

/// </summary>

public class BuildReports : IBuildReports

{

/// <summary>

/// Returns the Build Step Duration report for a given build

/// </summary>

/// <param name=»projectCollectionUri»>The Project collection Uri</param>

/// <param name=»teamProjectName»>The Team Project Name</param>

/// <param name=»buildDefinitionName»>The build definition name for the build for which the report should return the build duration. Only the latest build is extracted.</param>

/// <param name=»reportOption»>An enumeration that determines which steps should be returned</param>

/// <returns>A list of build steps with their respective duration</returns>

public IEnumerable<BuildStep> GetBuildStepDurationReport(string projectCollectionUri, string teamProjectName, string buildDefinitionName, BuildStepDurationReportOption reportOption)

{

ValidateBuildStepDurationParameters(projectCollectionUri, teamProjectName, buildDefinitionName);

var buildCollections = new Collection<BuildStep>();

var teamCollection = GetTeamCollection(projectCollectionUri);

var buildserver = teamCollection.GetService<IBuildServer>();

var buildDefinitionSpec = buildserver.CreateBuildDefinitionSpec(teamProjectName, buildDefinitionName);

var buildDetails = buildserver.QueryBuilds(buildDefinitionSpec);

if (buildDetails != null && buildDetails.Count() > 0)

{

var build = buildDetails.OrderByDescending(s => s.StartTime).FirstOrDefault();

build.Information

.GetSortedNodes(new BuildInformationComparer())

.ForEach(item => AddBuildInformation(buildCollections, item));

}

return buildCollections;

}

private static void ValidateBuildStepDurationParameters(string projectCollectionUri, string teamProjectName, string buildDefinitionName)

{

if (string.IsNullOrWhiteSpace(projectCollectionUri))

{

throw new ArgumentNullExceptionprojectCollectionUri«);

}

if (string.IsNullOrWhiteSpace(teamProjectName))

{

throw new ArgumentNullExceptionteamProjectName«);

}

if (string.IsNullOrWhiteSpace(buildDefinitionName))

{

throw new ArgumentNullExceptionbuildDefinitionName«);

}

if (!Uri.IsWellFormedUriString(projectCollectionUri, UriKind.Absolute))

{

throw new ArgumentExceptionMalformed Uri«, «projectCollectionUri«);

}

}

private static TfsTeamProjectCollection GetTeamCollection(string projectCollectionUri)

{

var teamCollection = TfsTeamProjectCollectionFactory.GetTeamProjectCollection( new Uri(projectCollectionUri.ToString(), UriKind.Absolute));

teamCollection.EnsureAuthenticated();

return teamCollection;

}     

private static void AddBuildInformation(Collection<BuildStep> collection, IBuildInformationNode buildInformation)

{    

if (buildInformation.Fields.ContainsKey(«StartTime«) && buildInformation.Fields.ContainsKey(«FinishTime«) && buildInformation.Fields.ContainsKey(«DisplayText«))

{

collection.Add(new BuildStep()

{

Name = buildInformation.Fields[«DisplayText«],

StartTime = DateTime.Parse(buildInformation.Fields[«StartTime«]),

EndTime = DateTime.Parse(buildInformation.Fields[«FinishTime«]),

Duration = DateTime.Parse(buildInformation.Fields[«FinishTime«]) — DateTime.Parse(buildInformation.Fields[«StartTime«])

});

}

}

internal class BuildInformationComparer : IComparer<IBuildInformationNode>

{

public int Compare(IBuildInformationNode itemToCompare, IBuildInformationNode itemToCompareWith)

{

if (itemToCompare.Id > itemToCompareWith.Id)

{

return 1;

}

else if (itemToCompare.Id == itemToCompareWith.Id)

{

return 0;

}

return -1;

}

}

}

Установка службы

  • Скопируйте папку «_Published» сервиса на ваш веб-сервер.
  • Создайте новый веб-сайт или виртуальный каталог и назначьте его на папку «_Published».
  • Создайте новый пул приложений и настройте его для запуска с учетной записью, имеющей следующие разрешения в командном проекте.
    • Удаление сборки
    • Обновление информации о сборке
    • Просмотр сборки.
    • Просмотр определения сборки.
  • Убедитесь, что параметр «Включить 32-битные приложения» в пуле приложений установлен в значение истина.
  • Ваш сервис теперь готов для использования.

Отчет «Длительность сборки с течением времени»

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

Таблица 5. Отчет «Длительность сборки с течением времени»

Рисунок 3. Отчет «Длительность сборки с течением времени»

Предварительные требования

  • Пользователю необходим доступ к базе данных TFS_<Название коллекции>, где <Название коллекции> имя коллекции команды.

Пример

Запрос может быть расширен для использования диапазона дат, чтобы увидеть результаты за период времени.

Ниже приводится краткое описание о каждой из таблиц, используемой в отчете:

  • tbl_Build – Таблица содержит записи для каждой командной сборки.
  • tbl_BuildQueue – В таблице хранятся сведения о том, когда конкретная сборка была поставлена в очередь.
  • tbl_BuildDefinition – Таблица определений сборок хранит информацию о созданном определении сборки.
  • tbl_BuildController – В таблице контроллер сборки хранит сведения о контроллере сборок
  • tbl_BuildInformation – таблица информации о сборке содержит сведения о сборке в отношении различных ее элементов. Например, для каждой сборки есть запись сборочной информации для Сообщения Сборки, Влияния На Тесты и т.д.
  • tbl_BuildInformationType — типы информации, которые хранятся в таблице информации о сборке, содержатся в таблице tbl_BuildInformationType

Код 5. Отчет «Длительность сборки с течением времени»

SELECT REPLACE(REPLACE(REPLACE(bd.DefinitionName, ‘\’, ») , ‘>’, »), ‘»‘,») AS BuildDefinitionName,

REPLACE(REPLACE(REPLACE(bld.BuildNumber, ‘\’, ») , ‘>’, »), ‘»‘,») AS BuildNumber,

CAST(DATEDIFF(SECOND, bld.StartTime, bld.FinishTime)/60 AS Decimal(5,1)) AS BuildDuration,

bld.[StartTime],bld.[FinishTime],[DropLocationRoot],bc.DisplayName AS BuildController

,RA.Field.value(‘(./Value)[1]’, ‘varchar(100)’) AS BuildAgent

FROM [dbo].[tbl_Build] bld

INNER JOIN tbl_BuildDefinition bd ON bld.DefinitionId = bd.DefinitionId

INNER JOIN tbl_BuildInformation bi ON bi.BuildId = bld.BuildId

INNER JOIN tbl_BuildController bc WITH(NOLOCK) ON bc.ControllerId = bld.ControllerId

INNER JOIN tbl_BuildInformationType bty WITH(NOLOCK) ON bi.NodeType = bty.NodeType

cross apply bi.Fields.nodes(‘/Fields/Field’) as RA(Field)

WHERE RA.Field.value(‘(./@Name)[1]’, ‘varchar(100)’) = ‘ReservedAgentName’

ORDER BY StartTime DESC

Отчет «Состояние сборки с течением времени»

Контекст Если вы ищете пути оптимизации сборки и пытаетесь понять, какая часть сборки занимает большую часть времени, то с использованием Visual Studio это иногда трудно понять. Visual Studio не облегчит эту задачу с помощью прокрутки бесконечного числа записей журнала.Отчет, описанный здесь, обеспечивает полезную альтернативу, показывая вам все сборки в командной коллекции в одном отчете с описанием времени начала, окончания и длительности сборок. Запрос может быть расширен диапазоном дат, чтобы увидеть результат за определенный период.
Версия TFS 2012
Категория Отчет о состоянии

Таблица 6. Отчет «Состояние сборки с течением времени»

Рисунок 4. Отчет «Состояние сборки с течением времени»

Предварительные требования

  • Пользователю необходим доступ к базе данных TFS_<Название коллекции>, где <Название коллекции> имя коллекции команды.

Пример

Следующий код работает для TFS 2012. Таблица очереди сборок (tbl_BuildQueue) не содержит исторические данные за последние 24 часа. Если вы хотите хранить больше данных, то вам нужно будет создать отдельную таблицу в другой базе данных.

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

  • tbl_Build – Таблица содержит записи для каждой командной сборки.
  • tbl_BuildQueue – В таблице хранятся сведения о том, когда конкретная сборка была поставлена в очередь.
  • tbl_BuildDefinition – Таблица определений сборок хранит информацию о созданном определении сборки.
  • tbl_BuildController – В таблице контроллер сборки хранит сведения о контроллере сборок
  • tbl_BuildInformation – таблица информации о сборке содержит сведения о сборке в отношении различных ее элементов. Например, для каждой сборки, есть запись сборочной информации для Сообщения Сборки, Влияния На Тесты и т.д.
  • tbl_BuildInformationType — типы информации, которые хранятся в таблице информации о сборки, содержатся в таблице tbl_BuildInformationType

Код 6. Отчет «Состояние сборки с течением времени»

SELECT REPLACE(REPLACE(REPLACE(bd.DefinitionName, ‘\’, ») , ‘>’, »), ‘»‘,») AS BuildDef

,bd.[Description]

—,bq.DateCreated

,bq.QueueTime AS ‘Queued Time UTC’

,REPLACE(REPLACE(REPLACE(b.BuildNumber, ‘\’, ») , ‘>’, »), ‘»‘,») AS BuildNumber

,b.StartTime AS ‘Build Start Time UTC’

,b.FinishTime AS ‘Build Finish Time UTC’

,DATEDIFF(SECOND ,bq.QueueTime, b.StartTime) AS ‘Queue Time Seconds’,

bc.DisplayName As BuildController,

RA.Field.value(‘(./Value)[1]’, ‘varchar(100)’) As BuildAgent

FROM tbl_Build b WITH(NOLOCK)

INNER JOIN tbl_BuildQueue bq WITH(NOLOCK) ON b.BuildId = bq.BuildId

INNER JOIN tbl_BuildDefinition bd WITH(NOLOCK) ON b.DefinitionId = bd.DefinitionId

INNER JOIN tbl_BuildController bc WITH(NOLOCK) ON bc.ControllerId = b.ControllerId

INNER JOIN tbl_BuildInformation bi WITH(NOLOCK) ON bi.BuildId = b.BuildId

INNER JOIN tbl_BuildInformationType bity WITH(NOLOCK) on bi.NodeType = bity.NodeType

cross apply bi.Fields.nodes(‘/Fields/Field’) as RA(Field)

WHERE RA.Field.value(‘(./@Name)[1]’, ‘varchar(100)’) = ‘ReservedAgentName’ AND bity.TypeName=‘AgentScopeActivityTracking’

Отчет «Среднее время между сбоями» (MBTF)

Контекст Отчет MTBF или среднее время между сбоями описывает среднее время между тем, когда проблема была найдена в промышленной среде, до момента, когда найдена следующая проблема.С точки зрения TFS возникновение проблемы отслеживается созданием рабочего элемента ошибки с типом «Ошибка». Таким образом, чтобы создать такой отчет, запрос будет искать рабочие элементы типа «Ошибка». Для получения информации мы будем использовать базу данных TfS_Warehouse, которая хранит всю информацию в соответствии со схемой звезда. В базе данных имеется таблица измерений, которая называется DimWorkItem и хранит все рабочие элементы. Однако, т.к. это таблица измерений, все изменения в любом поле в рабочем элементе приводят к новой строке в этой таблице. К счастью база данных Tfs_Warehouse также содержит представление таблицы измерений DimWorkItem, который возвращает текущее состояние каждого рабочего элемента. Представление, которое называется CurrentWorkItemView, — это то, что мы будем использовать в запросе.

Теперь, когда мы знаем, где находятся сведения о рабочем элементе, следующий фактор для рассмотрения – как определить время, прошедшее между созданием двух ошибок. Поле Microsoft_VSTS_Common_ActivatedDate содержит дату и время, когда рабочий элемент был создан, и это то, что мы будем использовать. Если мы сможем сортировать результаты и вычислить разницу между каждой соседней строкой в запросе, то у нас будет нужная информация. Предложения ROW_NUMBER и ORDER в SQL Server содержат необходимые функциональные возможности.

Заключительная часть мозаики – это фильтрация рабочих элементов. Т.к. затраченное время рассматривается в историческом контексте, мы будем фильтровать рабочие элементы, чтобы включать только те, которые закрыты по полю System_State и которые принадлежать данному командному проекту через поле ProjectPath.

Версия TFS 2012
Категория Отчет о рабочих элементам

Таблица 7. Отчет «Среднее время между сбоями»

Рисунок 5. Пример отчета «Среднее время между сбоями»

Предварительные требования

  • Пользователю необходим доступ к базе данных TFS_Warehouse.

Пример

CurrentWorkItemView – представление извлекает текущее состояние каждого рабочего элемента из таблицы измерений DimWorkItem.

Запрос выбирает все рабочие элементы типа «Ошибка» из данного командного проекта с состоянием «Закрыто» и отсортированными по Дате активации. Следующая задача заключается в том, чтобы вычислить разницу между двумя соседними записями. Для этого используется предложение ROWNUMBER и ORDER, чтобы дать уникальный номер для каждой строки результата. Затем результат объединяется по соседним строкам и вычисляет разницу между Дата активации для смежных рабочих элементов и затем с помощью статистической функции AVG определяется среднее количество часов.

Код 7. Отчет «Среднее время между сбоями»

DECLARE @ProjectPath varchar(255);

— Using this SELECT as just an example to get the latest build to view the details of

—SELECT @ProjectPath = ‘DefaultCollection\TeamProjectName’;

SELECT

RIGHT(‘0’ + CAST(DatePart(wk,CurrentBug.Date) as Varchar) + ‘/’ +

Cast(DatePart(yyyy,CurrentBug.Date) as Varchar), 7) as Week,

AVG(DateDiff(hh, FormerBug.Date, CurrentBug.Date)) as [MTBF in hours]

FROM

(SELECT (

ROW_NUMBER()

OVER(ORDER BY Microsoft_VSTS_Common_ActivatedDate asc) + 1) as ID,

Microsoft_VSTS_Common_ActivatedDate as Date

FROM

dbo.CurrentWorkItemView WITH (NOLOCK)

WHERE

System_WorkItemType = ‘Bug’

AND System_State = ‘Closed’

and ProjectPath like @ProjectPath

) as FormerBug

INNER JOIN

(SELECT (

ROW_NUMBER()

OVER(ORDER BY Microsoft_VSTS_Common_ActivatedDate asc)) as ID,

Microsoft_VSTS_Common_ActivatedDate as Date

FROM

dbo.CurrentWorkItemView WITH (NOLOCK)

WHERE

System_WorkItemType = ‘Bug’

AND System_State = ‘Closed’

and ProjectPath like @ProjectPath

) AS CurrentBug

ON FormerBug.ID = CurrentBug.ID

GROUP BY

DatePart(wk, CurrentBug.Date),

DatePart(yyyy, CurrentBug.Date)

Отчет «Среднее время решения проблем» (MTTR)

Контекст MTTR среднее время, прошедшее с момента, когда проблема обнаружена в промышленной среде, до момента, когда проблема устранена. Для того чтобы отслеживать MTTR, вы определяете данные, которые вам нужно, и как извлечь их из TFS. В шаблоне процесса MSF для гибкой разработки проблемы в промышленной среде представлены рабочим элементом ошибка, т.е. нужно отфильтровать по этому типу рабочего элемента и командному проекту.Не все ошибки, хранящиеся в командном проекте TFS, полезны для отслеживания MTTR. Нужны только те, которые были исправлены в промышленной среде. Также нужно фильтровать по командному проекту и нужно два поля для расчета MTTR. Первое поле — это момент, когда ошибка обнаружена в промышленной среде. Второе поле, когда ошибка исправлена и ее состояние становится закрытым. В шаблоне MSF для гибкой разработки это значение автоматически сохраняется в поле Дата закрытия.

Вы должны также принять решение о том, как представить данные в заключительном отчете. Расчет MTTR является временем, прошедшим между значениями Дата закрытия и Дата активации. Тем не менее, этот отчет будет более удобочитаемым, если будет скорректирован по значениям единиц времени и сгруппированы по результатам».

Версия TFS 2012
Категория Отчет о рабочих элементам

Таблица 8. Отчет «Среднее время решения проблем»

Рисунок 6. Пример отчета «Среднее время решения проблем»

Предварительные требования

  • Пользователю необходим доступ к базе данных TFS_Warehouse.

Пример

Код 8. Отчет «Среднее время решения проблем»

DECLARE @ProjectPath varchar(255);

— Using this SELECT as just an example to get the latest build to view the details of

—SELECT @ProjectPath = ‘DefaultCollection\TeamProjectName’;

SELECT

— We are adding a trailing ‘0’ for 1-digit week numbers,

— so we use the RIGHT function to remove it if was not

— needed because the week number had 2 digits.

RIGHT

(

‘0’

— Number of the week inside the year

+ CAST(DATEPART(wk, [Microsoft_VSTS_Common_ClosedDate])

AS VARCHAR)

— Separator

+ ‘/’

— Year

+ CAST(DATEPART(yyyy, [Microsoft_VSTS_Common_ClosedDate])

AS VARCHAR)

— Maximum length of the returned value (format: WW/YYYY)

, 7

) AS [Week]

— Mean Time To Recover, in hours, per each week

,AVG(

DATEDIFF(hh, [Microsoft_VSTS_Common_ActivatedDate],

[Microsoft_VSTS_Common_ClosedDate])

) AS [MTTR in hours]

FROM

[dbo].[CurrentWorkItemView] WITH(NOLOCK)

WHERE

[ProjectPath] like @ProjectPath = ‘\DefaultCollection\Lab04-Metrics’

AND [System_WorkItemType] = ‘Bug’

AND [System_State] = ‘Closed’

GROUP BY

— Grouping by week and year to calculate the average

DATEPART(wk, [Microsoft_VSTS_Common_ClosedDate]),

DATEPART(yyyy, [Microsoft_VSTS_Common_ClosedDate])

ORDER BY

— Ordering by year and week number

DATEPART(yyyy, [Microsoft_VSTS_Common_ClosedDate]) DESC,

DATEPART(wk, [Microsoft_VSTS_Common_ClosedDate]) DESC

Отчет «Отслеживание времени»

Контекст Отчет по отслеживанию времени отображает каждую версию рабочего элемента и его влияние на оставшуюся работу для данного рабочего элемента. Идея заключается в том, что люди обновляют рабочие элементы по выполнению части работы, они будут постоянно обновлять поле Оставшиеся трудозатраты. Отчет будет использовать этот запрос для отслеживания, сколько работы осталось.
Версия TFS 2010, TFS 2012
Категория Отчет о рабочих элементам

Таблица 9. Отчет «Отслеживание времени»

Рисунок 7. Пример отчета отслеживания времени в Scrum 2.2

Рисунок 7. Пример отчета отслеживания времени в MSF Agile

Предварительные требования

  • Пользователю необходим доступ к базе данных TFS_Warehouse.

Пример

Основные параметры

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

Параметр Применение
ProjectName Используется для фильтрации рабочих элементом. В отчете отображаются рабочие элементы только для командного проекта с заданным именем.

Таблица 10. Параметры отчета «Отслеживание времени»

Этот параметр устанавливается следующим образом:

Рисунок 7. Параметр отчета

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

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

Пошаговое руководство

Шаг Инструкции
1. Создайте проект отчета
[ ] – Сделано
  • Запустите BIDS (SQL Server Business Intelligence Development Studio)
  • Создайте новый проект Report Server Project MyCustomReport
2. Добавьте источник данных
[ ] – Сделано
  • В обозревателе решений нажмите правой кнопкой на DataSource, Add New Datasource и назовите его Tfs_Warehouse
  • Сделайте строку соединения и задайте учетные данные для чтения из базы данных Tfs_Warehouse.
3. Добавьте набор данных
[ ] – Сделано
  • В обозревателе решений, щелкните правой кнопкой мыши на DataSets, Add New DataSet
  • Задайте имя набора данных TimeTrackingDataset
  • Выберите источник данных Tfs_Warehouse
  • В Text Area for Query скопируйте и вставьте следующий SQL:

SELECT

[System_Id] As [Id],[System_Rev] As [Rev],

[System_ChangedBy] As [Changed By],

[Microsoft_VSTS_Scheduling_OriginalEstimate] AS [Original Estimate],

[Microsoft_VSTS_Scheduling_RemainingWork] AS [Remaining Work],

[Microsoft_VSTS_Scheduling_CompletedWork] AS [Completed Work],

[System_Title] As [Title],[System_AssignedTo] As [Assigned To],

[System_ChangedDate] As [Changed Date],

[ProjectNodeName] AS [Team Project],

[AreaName],[AreaPath],

[IterationName],

[IterationPath] ,

[Microsoft_VSTS_Scheduling_RemainingWork] — (Select Top 1 IsNull([Microsoft_VSTS_Scheduling_CompletedWork],0)

FROM [Tfs_Warehouse].[dbo].[WorkItemHistoryView] WITH(NOLOCK)

WHERE [System_Id] = WIHV.[System_Id]

AND [System_Rev] = WIHV.[System_Rev] — 1) as [Completed Diff]

FROM

[Tfs_Warehouse].[dbo].[WorkItemHistoryView] WIHV WITH(NOLOCK)

WHERE

/** Filter team project **/

[ProjectNodeName] LIKE @ProjectName

/** Filter correction entries **/

AND [RevisionCount] IS NOT NULL /** Filter empty entries **/

AND ([Microsoft_VSTS_Scheduling_OriginalEstimate] IS NOT NULL

OR [Microsoft_VSTS_Scheduling_RemainingWork] IS NOT NULL

OR [Microsoft_VSTS_Scheduling_CompletedWork] IS NOT NULL)

ORDER BY ID, Rev

  • Нажмите на пункт Parameters и установите флажок Default Value.
  • Установить значение по умолчанию как «%».
  • Нажмите кнопку ОК.
4. Добавьте отчет
[ ] – Сделано
  • В обозревателе решений нажмите правой кнопкой мыши Report, Add existing report и перейдите к отчету TimeTrackingReport.rdl
5. Установите запускаемый отчет для проекта
[ ] – Сделано
  • Щелкните правой кнопкой мыши на узел проекта и выберите Properties
  • Под Debug/Startitem выберите отчет
6. Протестируйте отчет
[ ] – Сделано
  • Нажмите F5 для сборки и тестирования отчета

 

 

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

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