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

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

Отчет по возрасту ошибок в 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 »

Работа с контейнерами и сервисами на основе Docker и Visual Studio Team Services

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

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

Возможности по интеграции Team Foundation Server и Oracle — Видео

Posted by Шамрай Александр на Январь 18, 2017

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

Использование TFS REST API на примере решения для учета времени, потраченного на задачи

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

На сегодняшний день TFS предоставляет следующие основные механизмы для взаимодействия со своими данными внешним приложениям:

  • TFS API на основе клиентский и серверных моделей взаимодействия, которые обеспечивают доступ ко всем необходимым функциям и объектам TFS. Для работы этого подхода необходимо иметь соответствующие библиотеки, которые позволят выполнять необходимые операции.
  • Командная строка tf, которая обеспечивает взаимодействие с сервером для операций с версионным контролем TFVC.
  • Набор инструментов TFS Power Tools дают дополнительные возможности для работы из командной строки для оперирования с рабочими элементами, запросами, а также дополнительные возможности для использования Power Shell.
  • TFS REST API взаимодействие с сервером TFS на основе запросов в формате Json. Этот механизм не настолько богат набором функций как первый, но является в общем достаточным для обеспечения интеграционных задач. Кроме этого плюсом данного механизма является то, что нет необходимости устанавливать клиентские библиотеки, а в случае с VS 2015 необходимо устанавливать всю студию, т.к. Team Explorer отдельно объектная модель не поставляется.

В рамках данного поста мы рассмотрим, как можно использовать Rest Api, чтоб получить информацию о рабочих элементах и зарегистрировать свои. Пример использования приложен к статье в виде таймтрекер клиента, который позволяет подсчитывать потраченное на активности время и привязывать это к конкретной задаче, ошибке и т.д. Основные операции, которые выполняются приложением через REST API:

  • Получение информации об активных рабочих элементах, назначенных на текущего пользователя.
  • Создание рабочего элемента Активность и его связывание с родительским рабочим элементом из предыдущего пункта.
  • Обновление информации о времени в родительском рабочем элементе.

Выполнение запросов к TFS

Взаимодействие с сервером TFS или службой VSO выполняется на основе HTTP запросов в формате JSON. Вся основная информация о доступных методах находится по следующему адресу: https://www.visualstudio.com/en-us/docs/integrate/api/overview

Для подключения к серверу и выполнения запросов используется HttpClient, пример использования которого отображен ниже:

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

  • GET – используется в основном для получения какой-либо информации, например, рабочего элемента или запроса по рабочим элементам.
  • POST – в рамках примера используется для выполнения запроса по рабочим элементам на основе Work item query language.
  • PATCH – для создания и обновления рабочих элементов. Т.к. данный пункт не реализован стандартными методами, то выполняется создание нового метода через new HttpMethod(«PATCH»).

Выполнение запросов на основе WIQL

В рамках примера WIQL используется для получения активных рабочих элементов. Подробнее можно посмотреть здесь: https://www.visualstudio.com/en-us/docs/integrate/api/wit/wiql.

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

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

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

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

В начале функции идет формирование строки запроса, которая имеет изначальный следующий вид:

string QueryWisReq = «{Url сервера}/{Имя коллекции}/_apis/wit/wiql?api-version=1.0»;

Далее создается экземпляр класса для запроса по рабочим элементам и его свойству присваивается соответствующее значение, в нашем случае задается запрос, который отбирает все назначенные на исполнителя рабочие элементы в состоянии Активно. Следующим шагом выполняется преобразование класса в JSON формат и его передача в тело запроса к серверу TFS с использованием метода POST. Результат запроса преобразовывается в экземпляр класса FlatQueryResult, из которого мы получаем необходимый для нас список идентификаторов рабочих элементов.

Создание рабочего элемента

Подробную информацию о доступных методах для оперирования с рабочими элементами можно посмотреть здесь: https://www.visualstudio.com/en-us/docs/integrate/api/wit/work-items. При создании нового рабочего элемента задается запрос, который в своем теле несет информацию о новых атрибутах, включающие в себя:

  • Информацию о полях и их значениях:

  • Информацию о ссылках:


Пример использования классов для создания рабочих элементов отображен ниже:

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

  • op – отражает операцию с полем, при присваивании значения можно использовать выражение «add»;
  • path – путь к полю, которое формируется через слияние строк «/fields/» и имя-ссылка на поле;
  • value – содержимое поля при создании рабочего элемента.

Кроме этого добавляется информация о ссылках. В данном случае добавляется ссылка для родительского элемента с системным наименованием «System.LinkTypes.Hierarchy-Reverse», которая также является заблокированной, т.е. ее невозможно удалить стандартными средствами TFS:

_lnks.value.attributes.isLocked = true;

Для создания рабочего элемента формируется запрос:

string urlCreateWI = «{Url сервера}/{Имя коллекции}/{Имя проекта}/_apis/wit/workitems/${Тип рабочего элемента}?api-version=1.0»;

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

Исходный код приложения для примера

Для того, чтобы посмотреть подробнее как используют приведенные выше примеры, а также другие методы, можно перейти по ссылке https://tfstimetracker.codeplex.com/

Использование приложения, которое приведено для примера

Данное решение выработано на основе предыдущих статей по учету рабочего времени Организация управления расписаниями (Timesheet) в TFS и позволяет автоматизировать учет потраченных часов на выполнение поставленных задач. Приложение выполняет следующие основные функции:

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

Рисунок 1.Настройка параметров подключения к TFS

Рисунок 2. Настройка рабочих элементов

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

Рисунок 3. Выбор активных задач с помощью меню

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

Рисунок 4. Сохранение информации о потраченном времени на задачу

Рисунок 5. Новая активность и родительская задача

Итог

Как видно из примера, использование REST API при работе с рабочими элементами обеспечивает достаточную функциональность и при этом невысокую сложность. Отдельным плюсом является то, что данный подход является кроссплатформенным без необходимости использования каких-либо отдельных клиентских библиотек.

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

Улучшения TFS 2015 Update 2 на примере работы с проблемами

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

TFS 2015 Update 2 предлагает много различных обновлений, включая релиз менеджер, который теперь доступен через Web-интерфейс, а также работает с VMWare и System Center. Но есть также как, казалось бы, небольшие, но полезные функции. Например, функция подстановки отображаемого имени пользователя через символ «@». С использованием этого нововведения можно улучшить некоторые процессы внутри команды разработки, например, управление проблемами.

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

  1. При большом количестве почты, включая обычно еще письма, в которых мы стоим просто в копии, получатель просто может упустить важное для него письмо и проблема долгое время остается незамеченной и нерешенной.
  2. Получатель может откладывать ответ для инициатора ввиду своей занятости, пока просто про него не забудет.
  3. Т.к. письмо в общем случае находится только в почтовых ящиках инициатора и получателя, то о процессе решения возникшей проблемы знает немного людей.
  4. Если в какой-то момент приходит точка Х, в которой нужно понять, что происходило, то это приводит к поиску в почтовом ящике, переборе потоков обсуждений и писем, а сделать это доступным для других участников можно только форвардом или распечатыванием потока обсуждения.
  5. Т.к. почта остается в личном ящике, то полученный опыт при решении проблем не может быть доступен для всех участников команды. А это может привести к повторному прохождению пути при решении схожих или этих же проблем.
  6. Невозможно понять сколько проблем у нас возникает, сколько мы решили, сколько еще нужно решить и сколько мы потратили на это времени.

Использование TFS может помочь упростить этот процесс:

  • Для управления проблемами в различных шаблонах существуют необходимые рабочие элементы, например, CMMI имеет Проблемы, Agile — препятствия, Scrum – также препятствия. Инициатор создает соответствующий рабочий элемент в командном проекте, назначает на исполнителя, который может решить проблему, и она доступна всем участникам разработки, включая руководителя проекта. Использование рабочего элемента позволяет определить правила обработки и эскалации при решении проблем.
  • Через символ «@» к решению проблемы можно привлечь необходимое количество людей, которые могут что-то подсказать или направить по нужному пути. Данную возможность можно использовать в комментариях для рабочего элемента, при этом им будет отправлено системой оповещение.

Рисунок 1. добавление участников к обсуждению

Рисунок 2. Пример нотификации

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

Рисунок 3. Пример запроса по рабочим элементам

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

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

Организация управления расписаниями (Timesheet) в TFS

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

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

TFS «из коробки» в принципе дает уже некоторые такие функции на основе задач и отчетности, что рассматривалось здесь ранее, но при этом нужно следовать строгим правилам:

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

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

  1. Возможность отслеживать активности связанные или не связанные с конкретными задачами.
  2. Возможность указывать дату для активностей, чтоб их можно было вносить пост фактом.
  3. Автоматизировать калькуляцию времени у задач, для которых существуют активности.
  4. Возможность собрать отчетную информацию.

Основная идея данного решения состоит в следующем:

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

Давайте рассмотрим эти шаги подробнее для TFS 2015 русской версии.

Ввести новый рабочий элемент Активность

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

  • Для редактирования мы воспользуемся TFS Power Tools и пример экспорта отображен на рисунке ниже:

Рисунок 1. Экспорт типа рабочего элемента

  • Далее мы открываем экспортированный файл и для определения типа рабочего элемента меняем его название:

Рисунок 2. Название типа рабочего элемента

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

Рисунок 3. Поле Дисциплина

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

Рисунок 4. Поле завершенной работы

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

Рисунок 5. Поле даты активности

Рисунок 6. Размещение даты активности на форме

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

Рисунок 7. Отслеживание изменения активности

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

Рисунок 8. Импорт нового типа рабочего элемента

Пример рабочего элемента Активность можно посмотреть в конце статьи.

Доработать рабочий элемент Задача

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

  • В этом случае выполняется изменение определения типа рабочего элемента Задача непосредственно на сервере без операций экспорта и импорта.

Рисунок 9. открыть рабочий элемент с сервера

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

Рисунок 10. Новая вкладка и контрол

Рисунок 11. Настройки контрола

В результате мы получим Задачу приблизительно в следующем виде:

Рисунок 12. Пример формы задачи

Написать решение, которое будет обновлять время у Задач

Решение можно реализовать различными подходами:

  1. Реализовать как серверный плагин. В данном случае выполняется разработка плагина, который «прослушивает» все события по изменению рабочих элементов и срабатывает только, когда выполняется работа с Активностями. Метод позволяет фактически моментально выполнять необходимые изменения, но будет дополнительно нагружать сервер TFS, особенно если происходит какое-то массовое изменение рабочих элементов.
  2. Реализовать как веб-сервис. TFS позволяет двумя различными методами подписываться на события, которые в нем происходят, и отправлять сообщения на SOAP сервисы. В данном случае мы будем получать только нужные для нас сообщения, но нужна дополнительная реализация самого сервиса, обработка входящих сообщений, а в дельнейшем также нужно задуматься, где его развернуть.
  3. Отдельное консольное приложение. В данном случае приложение работает на основе запроса по рабочим элементам, который будет получать необходимую информацию и выполнять операции по обновлению данных. В этом методе будет использоваться минимум кода, а развернуть его можно в виде периодической задачи на любом рабочем месте, включая сам сервер TFS, с предустановленными клиентскими библиотеками. Этот вариант проще для реализации, поэтому его мы и рассмотрим.

Основные шаги приложения будут следующими:

  • Подключение к хранилищу рабочих элементов и выполнения запроса. В нашем случае запрос отбирает информацию о ссылках активностей, которые связаны с задачами и были созданы или обновлены. Пример подключения и выполнения запроса:

WorkItemStore wiStore = new WorkItemStore(«http://tfs-srv:8080/tfs/DefaultCollection&#187;);

Query query = new Query(wiStore, QueryStr);

var result = query.RunLinkQuery();

  • Перебор результата запроса и получение связанных задач и активностей. Пример получения задач и активности:

WorkItem activity = wiStore.GetWorkItem(wilink.SourceId);

WorkItem task = wiStore.GetWorkItem(wilink.TargetId);

  • Получение информации о времени и обновление полей с временем у задачи. Пример операции:

Double work = (Double)activity.Fields[«Microsoft.VSTS.Scheduling.CompletedWork»].Value;

Field taskRemaining = task.Fields[«Microsoft.VSTS.Scheduling.RemainingWork»];

if (taskCompleted.Value == null) taskCompleted.Value = work;

else taskCompleted.Value = (Double)taskCompleted.Value + work;

task.Save();

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

foreach (WorkItemLink activityLink in activity.WorkItemLinks)

{
if (activityLink.LinkTypeEnd.Id == parentLink.Id)

{

if (activityLink.IsLocked) break;

activityLink.IsLocked = true;

break;

}

}

Пример приложения можно посмотреть в конце статьи.

Подготовить отчет

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

  • Открыть отчет «Ход реализации требований», который будет являться исходным. По умолчанию он находится в каталоге «Управление проектами». Сохраним отчет с новым именем.

Рисунок 13. Расположение исходного отчета

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

Рисунок 14. Параметр Activity

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

Рисунок 15. Пример изменения запроса

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

Рисунок 16. Выражение для поля Исполнитель

  • Далее нам необходимо протестировать и сохранить отчет:

Рисунок 17. Пример работы отчета

В итоге

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

Ресурсы

То, что использовалось в данной статье, можно скачать здесь:

  • Определение типа рабочего элемента Активность – Активность.xml.
  • Исходный код решения для обновления потраченного времени – UpdateCompletedFromActivity.zip.
  • Доработанный отчет по требованиям и их задачам и активностям – «Активности по требованиям.rdl».

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

Создание коллекции проектов TFS 2015 через API

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

Для автоматизации создания коллекции проектов используется метод QueueCreateCollection через интерфейс ITeamProjectCollectionService, который формирует задачу на создание новой коллекции. Этот метод имеет следующие параметры:

QueueCreateCollection(string name /*Название*/, string description /*Описание*/, bool isDefault /*коллекция по умолчанию*/, string virtualDirectory /*виртуальная директория*/, TeamFoundationServiceHostStatus state /*состояние после создания*/, IDictionary<string, string> servicingTokens /*сервисные данные*/);

Если с простыми параметрами все понятно, то сложность заключается в получении сервисных маркеров для портала проектов и сервера отчетности. Для создания используются следующие ключи:

  • SharePointAction со значениями CreateSite или None
  • SharePointSitePath – относительный путь для сайтов SharePoint в коллекции
  • SharePointServer – ключ сервера SharePoint
  • ReportingAction со значениями CreateFolder или None
  • ReportFolder – относительный путь для отчетности коллекции
  • ReportServer – ключ сервера отчетности

Пример:

Dictionary<string, string> servicingTokens = new
Dictionary<string, string>();

servicingTokens.Add(«SharePointAction», «CreateSite»);

servicingTokens.Add(«SharePointSitePath», «sites/» + newCollectionName);

servicingTokens.Add(«ReportingAction», «CreateFolder

servicingTokens.Add(«ReportFolder», «/TfsReports/» + newCollectionName);

Данные серверов отчетности и сайтов SharePoint можно получить из сервисной задачи создания коллекции TFS, которая выполнялась ранее. Она имеет название «Microsoft.TeamFoundation.JobService.Extensions.Core.ServicingJobExtension». Получить ключи можно по следующему примеру:

TeamFoundationJobDefinition[] _jobs = _jobservice.QueryJobs();

IEnumerable<TeamFoundationJobDefinition> _job = from a in _jobs where a.ExtensionName == «Microsoft.TeamFoundation.JobService.Extensions.Core.ServicingJobExtension»
select a;

if (_job.Count() > 0)

{


TeamFoundationJobDefinition _createcollection = _job.ElementAt(0);


XmlNodeList _nodes = _createcollection.Data.SelectNodes(«ServicingTokens/KeyValueOfStringString»);


foreach (XmlNode _node in _nodes)

{


if (_node.FirstChild.Name == «Key» && _node.FirstChild.InnerText == «SharePointServer») servicingTokens.Add(_node.FirstChild.InnerText, _node.LastChild.InnerText);


if (_node.FirstChild.Name == «Key» && _node.FirstChild.InnerText == «ReportServer») servicingTokens.Add(_node.FirstChild.InnerText, _node.LastChild.InnerText);

}

}

Теперь осталось выполнить формирование задачи для создания новой коллекции:

ITeamProjectCollectionService _tpcService = _tfsc.GetService<ITeamProjectCollectionService>();

ServicingJobDetail _createJob = _tpcService.QueueCreateCollection(newCollectionName, «Collection from console app», false, string.Format(«~/{0}/», newCollectionName), TeamFoundationServiceHostStatus.Started, servicingTokens);

TeamProjectCollection tpc = _tpcService.WaitForCollectionServicingToComplete(_createJob);

Пример можно скачать здесь.

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

Руководство по настройке шаблона процесса 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 »

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