DSL для программирования процессов в баг-трекере

Не бывает программного обеспечения без ошибок. Для учета ошибок в процессе разработки, как правило, используются баг-трекеры — программы, которые позволяют пользователям и тестировщикам сообщать о найденных ошибках, менеджерам — определять порядок исправления этих ошибок, а разработчикам — фиксировать факт исправления ошибок. Баг-трекер часто является основным средством взаимодействия команды разработки и пользователей, поэтому эффективность работы с ним так важна. В настоящее время выбор баг-трекеров достаточно велик. Среди них есть как бесплатные (Bugzilla, Mantis, Trac, Redmine), так и коммерческие системы (Jira, Fogbugz).

В нашей компании (JetBrains) долгое время использовалась Jira. Но в какой-то момент проблемы с производительностью и юзабилити этой системы заставили нас разработать свой собственный баг-трекер — YouTrack, ориентированный, как и другие продукты нашей компании, прежде всего на продуктивность команды. О системе YouTrack уже писали на Хабре два года назад, незадолго до выхода первой версии. С тех пор было уже три релиза, и теперь YouTrack для небольших команд стал бесплатным.

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

Настройка предполагает возможность

• задания набора полей, который есть у каждого отчета об ошибке (issue);
• определения жизненного цикла отчетов об ошибках;
• спецификации других аспектов принятого рабочего процесса (workflow).

Средства для задания набора полей в системе YouTrack достаточно предсказуемы.



Для каждого поля можно задать имя, множество значений, значение по умолчанию и т.д. То что в системе YouTrack все поля являются настраиваемыми не сказывается на производительности, благодаря использованию встроенной бессхемной базы данных (schema-less DB).

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

1. Формализация жизненного цикла отчетов об ошибках в виде набора таблиц. Можно определять правила переходов из состояния в состояние и действия при этих переходах, редактируя этот набор таблиц. При этом множество возможных действий предопределено заранее и ограничено. Такой способ программирования прост для неподготовленного пользователя, но недостаточно эффективен, потому что предполагает множество кликов мышкой там, где достаточно написать пару строк кода.
2. Описание жизненного цикла в конфигурационных файлах. Жизненный цикл тоже задается в виде автомата — те же состояния и переходы, но автомат программируется в текстовом виде. Такой способ задания во многом удобнее, но конфигурационные файлы создаются в обычных текстовых редакторах и интерпретируются в процессе работы баг-трекера. Вероятность ошибки при написании такого скрипта слишком велика.
3. Написание плагина на языке общего назначения, который реализует недостающую в баг-трекере функциональность для поддержания принятого рабочего процесса. Этот подход самый гибкий, но требует полноценной разработки, что может стать непреодолимым барьером для небольших команд.

Мы пришли к выводу, что задание рабочего процесса в баг-трекере — это всегда программирование в том или ином виде. Поэтому в системе YouTrack мы решили предоставить пользователю возможность описания рабочего процесса на предметно-ориентированном языке (domain specific langauge). Разумеется, для этого языка мы создали интегрированную среду разработки (IDE) с автодополнением, подсветкой синтаксиса, подсветкой ошибок, рефакторингами и т.п. Среда построена на базе системы метапрограммирования MPS, ранее упоминавшейся на Хабре.

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

1. Правила, описывающие реакцию на изменение отчета об ошибке независимо от его состояния (stateless rule).
2. Правила, которые могут срабатывать по расписанию для всех отчетов об ошибках, удовлетворяющих некоторому условию (schedule event rule).
3. Правила, которые задают реакцию на команды пользователя в виде автомата (statemachine).

Например, правило «при закрытии отчета об ошибке необходимо указать номер версии продукта, в которую вошли связанные с данной ошибкой исправления», может быть реализовано следующим образом:

Правила создаются в IDE и далее могут быть непосредственно загружены в YouTrack или экспортированы в виде zip-архива. Весь цикл создания правил проиллюстрирован в скринкасте на сайте JetBrains TV. Описание возможностей предметно-ориентированного языка и другие детали настройки YouTrack под процессы своей организации можно найти в документации.