DSL for programming processes in the bug tracker

There is no software without errors. To account for errors in the development process, bug trackers are usually used — programs that allow users and testers to report bugs, to managers to determine the order of correcting these errors, and to developers to fix the fact of correcting errors. A bug tracker is often the primary means of interaction between the development team and users, so the efficiency of working with it is so important. Currently, the choice of bug trackers is large enough. Among them are both free ( Bugzilla , Mantis , Trac , Redmine ) and commercial systems ( Jira , Fogbugz ).

In our company (JetBrains) Jira has been used for a long time. But at some point, problems with performance and usability of this system forced us to develop our own bug tracker - YouTrack , oriented, like other products of our company, primarily on the productivity of the team. About the system YouTrack already wrote on Habré two years ago, shortly before the release of the first version. Since then, there have already been three releases, and now YouTrack for small teams has become free.
')
The way to work with the bug tracker is highly dependent on the processes adopted in a particular company. Therefore, it is impossible to create a bug tracker that would fit everyone out of the box. Instead, it was necessary to provide users with the ability to easily configure the system for their processes.

Customization suggests the possibility

• specifying the set of fields that each error report has (issue);
• determine the life cycle of error reporting;
• specifications of other aspects of the adopted workflow (workflow).

The means for defining the set of fields in the YouTrack system are quite predictable.



For each field, you can specify a name, a set of values, a default value, etc. The fact that in the YouTrack system all fields are customizable does not affect performance, thanks to the use of the built-in schema-less DB.

It was much more difficult to determine how to set the workflow in the bug tracker. After examining existing implementations in other bug trackers, we identified the following approaches:

1. Formalization of the life cycle of error reports in the form of a set of tables. You can define rules for transitions from state to state and actions for these transitions by editing this set of tables. At the same time, many possible actions are predetermined and limited. This way of programming is simple for the unprepared user, but not effective enough, because it involves a lot of mouse clicks where it is enough to write a couple of lines of code.
2. Description of the life cycle in the configuration files. The life cycle is also defined as an automaton - the same states and transitions, but the automaton is programmed in text form. This way of setting is much more convenient, but the configuration files are created in ordinary text editors and are interpreted in the process of the bug tracker. The probability of an error when writing such a script is too great.
3. Writing a plug-in in a general-purpose language that implements the functionality missing in the bug tracker to support an adopted workflow. This approach is the most flexible, but requires full development, which can be an insurmountable barrier for small teams.

We came to the conclusion that the task of the workflow in the bug tracker is always programming in one form or another. Therefore, in the YouTrack system, we decided to provide the user with the ability to describe the workflow in domain specific langauge. Of course, for this language we created an integrated development environment (IDE) with autocompletion, syntax highlighting, error highlighting, refactoring, etc. The environment is based on the MPS metaprogramming system previously mentioned on Habré .

In terms of this language, a workflow is a related set of rules. Rules can be of one of three types:

1. The rules that describe the reaction to a change in the error report, regardless of its state (stateless rule).
2. Rules that can be triggered by a schedule for all error reports that satisfy a certain condition (schedule event rule).
3. The rules that set the reaction to user commands in the form of a machine (statemachine).

For example, the rule “when closing an error report, you must specify the version number of the product that includes corrections related to this error” can be implemented as follows:

Rules are created in the IDE and then can be directly uploaded to YouTrack or exported as a zip archive. The whole cycle of creating rules is illustrated in a screencast on JetBrains TV. A description of the capabilities of a subject-oriented language and other details on how YouTrack can be configured for its organization can be found in the documentation .