Личный опыт: организация Workflow в трекере TFS

9188dd9c8ba74cf5861a2e3f58f48be3.png

Мы продолжаем рассказывать о процессах организации разработки в Positive Technologies. Ранее мы коснулись тем создания дистрибутивов продуктов, организации процесса хранения и лицензирования софта и реализации собственной системы Continuous Integration.

Сегодня речь пойдет о том, как мы используем инструмент Team Foundation Server (TFS) для организации workflow разработки.

Немного о TFS


Team Foundation Server состоит из нескольких компонентов.

Система контроля версий:

4d000021f406452ea9a7fa34cd6058a9.png

Трекер задач:

b1909d78bfcc42bf9570054a4381044c.png

Система непрерывной интеграции:

58e85fae7d6044c1bb7e853479871e31.png

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

TFS для трекинга задач и организации Workflow


Система поддерживает методологии разработки, такие как Kanban, Scrum, CMMI. Кроме того, поддерживаются различные — в том числе кастомные — типы задач: Bug, Task, Feature, User Story и т.п. Также стоит отметить гибкую систему изменения Workflow-задач.

Базовый Workflow для задачи Bug в TFS выглядит следующим образом:

65451984502b4fb29b834c9ad278ecac.jpg

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

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

7191b48d52954b578c16c7e35c594ab3.jpg

Расширение Workflow было выполнено путем добавления новых статусов и переименования существующих. Например, были добавлены статусы Rejected — для задач, которые были отклонены по каким-либо причинам, Moved — для задач, перенесенных в другой проект, Pending — для задач, которые были временно приостановлены.

Переименованные статусы: Approved стал называться In Progress, он значит, что задача была взята в работу, а Commited переименовали в Resolved, означающий, что задача была решена и требуется подтверждение ее выполнения, либо дополнительные работы по ней.

Аналогичным образом изменяется и внешний вид карточки Bug. В самом начале после создания проекта она выглядит так:

237731eeeca14d84aa8cdabc0b856510.jpg

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

18de997d34264fa983475270ae41ebea.jpg

Мы добавили колонку с полями для тайм-трекинга (Original Estimate, Remaining Work, Completed Work, Daily Work), в шаги воспроизведения был добавлен шаблон для заполнения HTML, а также появилась классификация багов по различным признакам.

Проблемы и решения


Несмотря на удобство системы, при работе с Workflow в трекере TFS есть и ряд сложностей:
  • Нет рассчитываемых полей — «навешивание» на полей дополнительной логики трудно реализуется, даже перенос временных метрик из дочерних элементов в родительские не предусмотрен.
  • Нет поля множественного выбора — если в Bug или каком-либо другом work item есть поле клиент, а ошибка встречается у нескольких клиентов, то выбрать их всех нельзя, возможно только одно значение.
  • Неудобный процесс изменения полей и их типов — если в названии поля была допущена ошибка, то исправить ее нельзя, требуется пересоздание поля с переносом всех значений в новое.
  • Нельзя отслеживать изменения и откатывать их — все шаблоны багов и конфигурации TFS хранятся в виде XML, загружаемых в базы. Если допустить ошибку и залить ее в базу, то откатиться на предыдущую версию не удастся. Так что нужно самостоятельно помнить, где и что ты менял.
  • Неудобная система прав для изменения workflow и списков — она устроена таким образом, что если дать пользователю права на изменение списков полей, то он автоматически получит права на изменение списков всего workflow.

Мириться с этими недостатками нам не хотелось, поэтому пришлось решать возникающие проблемы. Вот что мы сделали:
  • Стали использовать открытый проект TfsAggregator для расчета логики полей — удобный инструмент для расчета time tracking-полей, проброса текстовых значений из одного рабочего элемента в другой и т.д.
  • WitCustomControls для реализации поля комбобокса — еще один открытый проект, Java-Script-плагин, позволяющий создавать поля множественного выбора.
  • Gitlab для хранения и трекинга шаблонов рабочих элементов — помогает отслеживать изменения в конфигурациях и дает возможность откатиться на предыдущую версию в случае ошибки.
  • Изменения в шаблоны рабочих элементов, списков и пр. разрешено вносить только администраторам сервиса TFS — это сделано для снижения риска несанкционированного изменения каких-либо конфигураций, списков и т.д.

P.S. Рассказ о разработанном нами инструментарии для создания дистрибутивов был представлен в рамках DevOps-митапа, который состоялся осенью в Москве.

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

Автор: Алексей Соловьев

Комментарии (0)

© Habrahabr.ru