Мы продолжаем рассказывать о процессах организации разработки в Positive Technologies. Ранее мы коснулись тем создания дистрибутивов продуктов, организации процесса хранения и лицензирования софта и реализации собственной системы Continuous Integration.
Сегодня речь пойдет о том, как мы используем инструмент Team Foundation Server (TFS) для организации workflow разработки.
Немного о TFS
Team Foundation Server состоит из нескольких компонентов.
Система контроля версий:
Трекер задач:
Система непрерывной интеграции:
Для нашей компании TFS в первую очередь — это трекер задач, которым пользуется большинство команд. Второй по популярности сценарий использования — система контроля версий, в которой хранится не так много проектов, но все они активно разрабатываются. По остаточному принципу используем TFS и в качестве сборочной системы — для тех же самых проектов, версии которых в ней хранятся.
TFS для трекинга задач и организации Workflow
Система поддерживает методологии разработки, такие как Kanban, Scrum, CMMI. Кроме того, поддерживаются различные — в том числе кастомные — типы задач: Bug, Task, Feature, User Story и т.п. Также стоит отметить гибкую систему изменения Workflow-задач.
Базовый Workflow для задачи Bug в TFS выглядит следующим образом:
Мы видим n статусов — начальный, конечный и переходы между состояниями. Как правило, на базовом workflow мало кто работает — всегда возникает необходимость его расширения.
Измененный процесс в нашем случае может выглядеть примерно так:
Расширение Workflow было выполнено путем добавления новых статусов и переименования существующих. Например, были добавлены статусы Rejected — для задач, которые были отклонены по каким-либо причинам, Moved — для задач, перенесенных в другой проект, Pending — для задач, которые были временно приостановлены.
Переименованные статусы: Approved стал называться In Progress, он значит, что задача была взята в работу, а Commited переименовали в Resolved, означающий, что задача была решена и требуется подтверждение ее выполнения, либо дополнительные работы по ней.
Аналогичным образом изменяется и внешний вид карточки Bug. В самом начале после создания проекта она выглядит так:
В базовом виде система предоставляет немного информации — как минимум, отсутствует шаблон для шагов воспроизведения, никаких временных метрик и других необходимых нам полей. Такой дефицит нас не устроил, поэтому внешний вид карточки мы также переработали под свои нужды.
Мы добавили колонку с полями для тайм-трекинга (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 докладов, представленных в ходе мероприятия. Все презентации и видео выступлений будут добавлены в таблицу в конце этого топика-анонса.
Автор: Алексей Соловьев
P. P. S. Напоминаем, что совсем скоро при поддержке Positive Technologies в Москве пройдет курс по asyncio+aiohttp от Core-разработчика Python Андрея Светлова.
Мы хотим предложить один бесплатный билет на семинар автору лучшего вопроса для Андрея — вопрос выберет он сам и ответит на него в ходе занятия. Присылайте свои вопросы по адресу: asyncio2016@ptsecurity.com.
