Не бывает программного обеспечения без ошибок. Для учета ошибок в процессе разработки, как правило, используются баг-трекеры — программы, которые позволяют пользователям и тестировщикам сообщать о найденных ошибках, менеджерам — определять порядок исправления этих ошибок, а разработчикам — фиксировать факт исправления ошибок. Баг-трекер часто является основным средством взаимодействия команды разработки и пользователей, поэтому эффективность работы с ним так важна. В настоящее время выбор баг-трекеров достаточно велик. Среди них есть как бесплатные (Bugzilla, Mantis, Trac, Redmine), так и коммерческие системы (Jira, Fogbugz).
В нашей компании (JetBrains) долгое время использовалась Jira. Но в какой-то момент проблемы с производительностью и юзабилити этой системы заставили нас разработать свой собственный баг-трекер — YouTrack, ориентированный, как и другие продукты нашей компании, прежде всего на продуктивность команды. О системе YouTrack уже писали на Хабре два года назад, незадолго до выхода первой версии. С тех пор было уже три релиза, и теперь YouTrack для небольших команд стал бесплатным.
Способ работы с баг-трекером сильно зависит от процессов, принятых в той или иной компании. Поэтому создать баг-трекер, который подошел бы всем «прямо из коробки», невозможно. Вместо этого необходимо было предоставить пользователям возможность удобной настройки системы под свои процессы.
Настройка предполагает возможность
- задания набора полей, который есть у каждого отчета об ошибке (issue);
- определения жизненного цикла отчетов об ошибках;
- спецификации других аспектов принятого рабочего процесса (workflow).
Средства для задания набора полей в системе YouTrack достаточно предсказуемы.
Для каждого поля можно задать имя, множество значений, значение по умолчанию и т.д. То что в системе YouTrack все поля являются настраиваемыми не сказывается на производительности, благодаря использованию встроенной бессхемной базы данных (schema-less DB).
С тем, как следует задавать в баг-трекере рабочий процесс, определиться было значительно сложнее. Изучив существующие реализации в других баг-трекерах, мы выявили следующие подходы:
- Формализация жизненного цикла отчетов об ошибках в виде набора таблиц. Можно определять правила переходов из состояния в состояние и действия при этих переходах, редактируя этот набор таблиц. При этом множество возможных действий предопределено заранее и ограничено. Такой способ программирования прост для неподготовленного пользователя, но недостаточно эффективен, потому что предполагает множество кликов мышкой там, где достаточно написать пару строк кода.
- Описание жизненного цикла в конфигурационных файлах. Жизненный цикл тоже задается в виде автомата — те же состояния и переходы, но автомат программируется в текстовом виде. Такой способ задания во многом удобнее, но конфигурационные файлы создаются в обычных текстовых редакторах и интерпретируются в процессе работы баг-трекера. Вероятность ошибки при написании такого скрипта слишком велика.
- Написание плагина на языке общего назначения, который реализует недостающую в баг-трекере функциональность для поддержания принятого рабочего процесса. Этот подход самый гибкий, но требует полноценной разработки, что может стать непреодолимым барьером для небольших команд.
Мы пришли к выводу, что задание рабочего процесса в баг-трекере — это всегда программирование в том или ином виде. Поэтому в системе YouTrack мы решили предоставить пользователю возможность описания рабочего процесса на предметно-ориентированном языке (domain specific langauge). Разумеется, для этого языка мы создали интегрированную среду разработки (IDE) с автодополнением, подсветкой синтаксиса, подсветкой ошибок, рефакторингами и т.п. Среда построена на базе системы метапрограммирования MPS, ранее упоминавшейся на Хабре.
В терминах этого языка рабочий процесс представляет собой связанный набор правил. Правила могут быть одного из трех типов:
- Правила, описывающие реакцию на изменение отчета об ошибке независимо от его состояния (stateless rule).
- Правила, которые могут срабатывать по расписанию для всех отчетов об ошибках, удовлетворяющих некоторому условию (schedule event rule).
- Правила, которые задают реакцию на команды пользователя в виде автомата (statemachine).
Правила создаются в IDE и далее могут быть непосредственно загружены в YouTrack или экспортированы в виде zip-архива. Весь цикл создания правил проиллюстрирован в скринкасте на сайте JetBrains TV. Описание возможностей предметно-ориентированного языка и другие детали настройки YouTrack под процессы своей организации можно найти в документации.