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

^[1]

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

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

Немного о TFS

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

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

^[5]

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

^[6]

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

^[7]

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

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

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

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

^[8]

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

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

^[9]

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

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

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

^[10]

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

^[11]

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

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

Несмотря на удобство системы, при работе с Workflow в трекере TFS есть и ряд сложностей:

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

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

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

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

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

Автор: Алексей Соловьев ^[17]

Автор: Positive Technologies

Источник ^[18]