DSL for programming processes in a bug tracker

    Custom bird

    There is no software without errors. To account for errors in the development process, as a rule, bug trackers are used - programs that allow users and testers to report errors found, managers - determine the procedure for fixing these errors, and developers - record the fact of error correction. A bug tracker is often the main means of interaction between the development team and users, so the effectiveness of working with it is so important. Currently, the choice of bug trackers is quite large. Among them there are both free ( Bugzilla , Mantis , Trac , Redmine ), and commercial systems ( Jira , Fogbugz ).

    Our company (JetBrains) has been using Jira for a long time. But at some point, problems with the performance and usability of this system forced us to develop our own bug tracker - YouTrack , focused, like other products of our company, primarily on the productivity of the team. YouTrack was already written about the system on Habré two years ago, shortly before the release of the first version. Since then there have been three releases, and now YouTrack for small teams has become free.

    The way you work with the bug tracker is highly dependent on the processes adopted by a particular company. Therefore, creating a bug tracker that would suit everyone “right out of the box” is impossible. Instead, it was necessary to provide users with the ability to conveniently configure the system for their processes.

    Customization implies the possibility
    • setting the set of fields that each error report has (issue);
    • defining the life cycle of error reporting;
    • Specifications other aspects of the received workflow (workflow).

    Tools for setting a set of fields in the YouTrack system are fairly predictable.

    Interface for editing fields in a project in YouTrack

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

    It was much more difficult to determine how the workflow should be set in the bug tracker. Having studied the 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 the rules for transitions from state to state and actions during these transitions by editing this set of tables. Moreover, many possible actions are predetermined in advance and limited. This programming method is simple for an 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 set in the form of an automaton - the same states and transitions, but the automaton is programmed in text form. This way of setting is in many ways more convenient, but configuration files are created in ordinary text editors and interpreted during the operation of the bug tracker. The probability of an error when writing such a script is too high.
    3. Writing a plugin in a general-purpose language that implements the functionality missing in the bug tracker to maintain an accepted workflow. This approach is the most flexible, but requires full development, which can become 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 opportunity to describe the workflow in a domain-specific language (domain specific langauge). Of course, for this language we have created an integrated development environment (IDE) with auto-completion, syntax highlighting, error highlighting, refactoring, etc. The environment is built on the basis of the MPS metaprogramming system , previously mentioned on Habré .

    In terms of this language, a workflow is a related set of rules. Rules can be one of three types:
    1. Rules describing the reaction to a change in the error report regardless of its state (stateless rule).
    2. Rules that can be triggered by schedule for all error reports that satisfy a certain condition (schedule event rule).
    3. Rules that define the reaction to user commands in the form of an automaton (statemachine).
    For example, the rule "when closing the error report, you must specify the version number of the product that includes the corrections associated with this error," can be implemented as follows:
    Assert fixed version is set for fixed issue
    Rules are created in the IDE and can then be directly downloaded to YouTrack or exported as a zip archive . The entire rules creation cycle is illustrated in the screencast on the JetBrains TV website. A description of the features of the subject-oriented language and other details of YouTrack settings for the processes of your organization can be found in the documentation .

    Also popular now: