Wie wir Jira Query Language in der Praxis verwenden

Hallo, alle miteinander!



Mein Name ist Sergey Rakov, ich bin Leiter der B2G-Abteilung bei Rostelecom IT. Ich möchte Ihnen etwas über die Jira Query Language (JQL) erzählen: wie man sie in der Praxis einsetzt, grundlegende Techniken, auf welche Probleme wir gestoßen sind und wie wir sie gelöst haben.



Originalbild von deviniti.com/atlassian



Es gibt viele Task-Tracker, von denen jeder zur Lösung einiger Probleme geeignet und bei der Lösung anderer nicht sehr hilfreich ist. Wir haben viele davon verwendet, aber jetzt haben wir uns für Jira entschieden - es ist unser Hauptwerkzeug. Persönlich mag ich die JQL-Sprache sehr, die die Arbeit erheblich vereinfacht und es Ihnen ermöglicht, ein leistungsstarkes und flexibles Tool zum sofortigen Auffinden von Tickets zu haben.



Jira bietet sofort einfache und erweiterte Suchfunktionen. Diese beiden Suchoptionen können die meisten Probleme des Benutzers lösen. Die grundlegende Suche ist jedem bekannt, der die Dienste von Online-Shops mindestens einmal in Anspruch genommen hat - sie funktioniert nach demselben einfachen Schema. Es gibt viele Filter: nach Projekten, Aufgabentypen, nach Executor und Status. Sie können auch zusätzliche Felder hinzufügen, die auf von Jira unterstützten Kriterien basieren.



Ein Problem tritt jedoch auf, wenn Sie über grundlegende Abfragen hinausgehen müssen. Zum Beispiel, wenn wir Aufgaben suchen möchten, die jemals für einen bestimmten Darsteller ausgeführt wurden, oder alle Aufgaben mit Ausnahme eines Projekts suchen möchten. Mit der Basissuche ist es nicht mehr möglich, eine schwierige Auswahl für ein Projekt mit einem Aufgabenstatus und einem Ausführenden und einem weiteren Ausführenden und einem anderen Aufgabenstatus zu treffen.



Erweiterte Suche hilft. Die JQL-Syntax ist SQL sehr ähnlich. In JQL ist es jedoch nicht erforderlich, bestimmte Felder auszuwählen, die wir auswählen, Tabellen und Datenbanken anzugeben, aus denen wir anzeigen möchten. Wir geben nur einen Block mit Bedingungen an und arbeiten mit der Sortierung - den Rest erledigt Jira automatisch.



Alles, was Sie wissen müssen, um mit JQL zu arbeiten, sind die Namen der Felder, anhand derer wir Tickets, Operatoren ( = ,! =, <,>, In, nicht in, was, ist usw.), Schlüsselwörter ( AND ) auswählen , OR, NOT, EMPTY, ORDER BY usw.) und Funktionen, die im erweiterten Modus ( Now (), CurrentUser (), IssueHistory (), EndOfDay () und andere) sofort verfügbar sind .

Felder

Wenn Sie in die Suchleiste eingeben, gibt Jira selbst Hinweise auf alle möglichen Werte, nach denen Sie suchen: sowohl nach Feldern als auch nach den Werten dieser Felder. Für mich habe ich kürzlich ein interessantes Systemfeld lastViewed entdeckt . Jira verfolgt Ihre Ticketansichten.



Hier sind zwei Optionen zum Erstellen von Filtern zum Anzeigen der letzten Aufgaben. Die erste ist meine lastViewed-Option , bei der Jira die Probleme, die ich in den letzten sieben Tagen angezeigt habe, in absteigender Reihenfolge sortiert zurückgibt . Dieser Filter ist in meinem Dashboard als Gadget eingerichtet und wird häufig verwendet. Da das Ticket geschlossen war, erinnerte ich mich nicht an den Tab und die Nummer, ich öffnete es schnell und schaute, was das letzte Ticket war.



Es gibt einen Standardfilter, der kürzlich angezeigt wurde. Es verwendet die Funktion IssueHistory () . Die Sortierung erfolgt ebenfalls nach dem Feld lastViewed . Das Ergebnis ist das gleiche, aber die Methode kann auch in Jira unterschiedlich angewendet werden. Es ist zu beachten, dass die Felder LastViewed und IssueHistory () nur Ihren Browserverlauf zurückgeben. Auf diese Weise können Sie den Verlauf Dritter nicht anzeigen.





Zum größten Teil hat Jira Standardoperatoren. Meine Lieblingsoperatoren sind WAS , WAS IN , WAS NOT IN , WAS NOT , GEÄNDERT, weil sie mit der Zeit arbeiten. Dies ist in herkömmlichen Datenbanken nicht möglich.







Mit Jira können Sie sofort mit historischen Daten arbeiten. Mit dem WAS- Operator können Sie Tickets finden, bei denen der Executor User1 war und ist. Wenn das Ticket bei mir war und dann an eine andere Person weitergegeben wurde, zeigt die Anfrage, dass dieses Ticket einmal bei mir war. Es ist klar, dass Sie für eine detailliertere Auswahl weitere Bedingungen hinzufügen müssen, aber wir werden später darauf zurückkommen.



Es gibt jedoch eine Einschränkung: Jira speichert keinen Verlauf für Textfelder: Ticketnamen und deren Beschreibungen. Sie können dort nicht schreiben: " Bringen Sie mir Tickets, in denen das Feld Zusammenfassung das Wort" Rostelecom "enthielt ."



Zweites Beispiel mit dem Operator CHANGED . Wir möchten Tickets erhalten, bei denen der Testamentsvollstrecker nach dem 1. Januar 2020 gewechselt wurde. Sie können andere zusätzliche Wörter verwenden, z. B. VOR oder Zeichen>, <, für die es bequemer ist, und ein bestimmtes Datum. Im selben Beispiel können Sie auch eine Negation vornehmen und sehen, welche Tickets auf welchen Benutzern stecken : Der Empfänger wurde nach '2020-01-01' nicht geändert .

Stichworte

Die wichtigsten Stichworte sind OR , AND , NOT . Sie funktionieren genauso wie logische Operatoren. Mit OR erhalten wir einen vollständigen Satz von Tickets aus zwei Projekten A und B. Wenn wir die Auswahl eingrenzen müssen, verwenden wir AND . Beispiel - Wir benötigen Tickets aus dem Entwurf A, auf dem der Benutzer Bed ausgeführt hat, und: project = A = Bed und den AND-Empfänger . So ist es auch mit Verleugnung.

Funktionen

Laut Dokumentation gibt es in Jira 47 Funktionen, aber ich habe nie alle verwendet. Hier sind meiner Meinung nach einige der wichtigsten:







now () ist eine beliebte Funktion, mit der Sie Tickets finden können, die beispielsweise abgelaufen sind.



currentUser () gibt den aktuellen Benutzer zurück. Jira enthält vorkonfigurierte Filter, die diese Funktion verwenden. Mit currentUser () können Sie generische Suchvorgänge durchführen. So habe ich ein universelles Dashboard für das gesamte Entwicklungsteam erstellt: Ich habe Gadgets in das Dashboard gestopft und in jedem habe ich currentUser () anstelle eines bestimmten Benutzers angegeben . Dieses Dashboard ist für jeden angemeldeten Benutzer eindeutig, obwohl die Konfiguration identisch ist.



noneasedVersions () ist eine Funktion, die Tickets in unveröffentlichten Versionen zurückgibt. Es werden jedoch keine Tickets zurückgegeben, die keine Version haben.



startOfDay () gibt den Beginn des aktuellen Tages zurück. Es gibt Funktionen für Woche, Monat und Jahr. Gleiches gilt für die Schließfunktion endOfDay () . Sie ermöglichen es Ihnen, bestimmte Daten zu entfernen , und es können Argumente angegeben werden: Wenn Sie startOfDay (-1) schreiben , wird der Anfang des vorherigen Tages zurückgegeben. Wenn Sie alles so lassen, wie es ist, wird der Beginn des aktuellen Tages angezeigt - die Ausgabe ist die Uhrzeit. Diese Funktionen helfen, Hardcode zu vermeiden, wir verwenden sie häufig.



Aus issueHistory ()Ich habe bereits ein Beispiel gegeben, diese Funktion gibt nur eine Liste Ihrer Ansichten zurück.



linkedIssues () ist eine Funktion, mit der Sie Tickets finden können, die mit einem bestimmten Ticket verknüpft sind.



Dies sind die einfachsten Funktionen. Aber lassen Sie uns etwas tiefer eintauchen und komplexere Zusammenhänge betrachten.

assignee was currentUser()

AND fixVersion was in
unreleasedVersions()

AND created > startOfYear()

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Ein bisschen synthetisches Beispiel, aber trotzdem. Dies ist eine einzelne Abfrage, die in drei Blöcke unterteilt ist. Nach Abschluss des ersten Teils der Anfrage erhalten wir Tickets, auf denen ich jemals Performer war oder bin. Es ist sehr wichtig, dass WAS nicht nur existierte, sondern immer noch existiert.



Im zweiten Teil wird die Filterung hinzugefügt: Wir filtern die empfangenen Bereiche meiner Tickets, die derzeit noch in unveröffentlichten Versionen vorliegen. Das heißt, wenn es in dieser unveröffentlichten Version ein Ticket gab und es im Moment noch nicht veröffentlicht wurde, aber ich das Ticket dann auf eine andere Version übertragen habe und es bereits freigegeben wurde, wird das Ticket in diese Auswahl aufgenommen.



Die dritte Bedingung ist das Erstellungsdatum. Wir filtern nur die Tickets, die seit Beginn des laufenden Jahres erstellt wurden.

ScriptRunner

Dies ist ein Plugin, das die Fähigkeiten von Jira erheblich verbessert. Es wird normalerweise zur Automatisierung von Prozessen verwendet, fügt JQL jedoch auch viele zusätzliche Funktionen hinzu. ScriptRunner war unser erstes Plugin, das wir bereitstellten, sobald wir zu Jira wechselten - Ende 2018. Ich habe sehr aktiv darum gebeten, dieses Plugin zu installieren, da ich ohne es keine Daten über Links zu Epen sammeln könnte. Zum Beispiel musste ich oft alle epischen Tickets für eine bestimmte Anfrage oder alle epischen Tickets für Unterabfragen zurückgeben. Mit ScriptRunner können Sie all dies erfolgreich ausführen.



Um ScriptRunner-Funktionen verwenden zu können, müssen Sie in JQL ein zusätzliches Wort issueFunction hinzufügen oder nicht . Als nächstes kommt zum Beispiel die Funktion epicsOf () - Gibt Ticket-Epics zurück, die den Unterabfragebedingungen entsprechen. Die Unterabfrage steht in der zweiten Zeile in Klammern, und wir werden sie uns genauer ansehen.

issueFunction in epicsOf
("worklogDate >= startOfWeek(-1) AND worklogDate <= endOfWeek(-1)")
AND project in (".B2G")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Im ersten Beispiel suchen wir nach Epen mit Zeitabschreibungen für die letzte Woche. Life Hack für Teamleiter und Manager: Wenn Sie vergessen haben, die Arbeitszeitnachweise auszufüllen, und sich nicht daran erinnern, was Sie letzte Woche getan haben, werden Sie durch Ausfüllen dieser Anfrage sehen, an welchen Epen das Team gearbeitet hat. Und höchstwahrscheinlich haben Sie auch daran gearbeitet, weil das Team eindeutig Fragen hatte. Im Allgemeinen hilft diese Abfrage dabei, sich daran zu erinnern, was Sie getan haben, und alles ist gut zu malen.



Die Abfrage selbst wird in Klammern ausgeführt, dh in der Unterabfrage worklogDate - dem Datum der Belastung. Weiter gibt es eine Spezifikation > = startOfWeek (-1) - den Beginn der Woche. Aber achten Sie auf die Zahl -1: Das bedeutet, dass wir diesen Montag nicht brauchen, sondern den letzten. Und auch worklogDate <= endOfWeek (-1)Das heißt, es ist weniger als Ende letzter Woche. Diese Anfrage stellt Tickets aus, egal was passiert - Fehler, Aufgaben, User Stories - für die Mitarbeiter letzte Woche die Zeit von Montag bis Sonntag abgeschrieben haben.



Der Trick besteht darin, dass Sie mit den Funktionen startOfWeek () und endOfWeek () das Datum entfernen können . Unabhängig von der Zeit, in der ich diese Anfrage in der aktuellen Woche stelle, wird sie mir den gleichen epischen Umfang zurückgeben. Sobald diese Woche endet, wird er die Epen dafür zurückgeben. Überraschenderweise nutzt nicht jeder diese Gelegenheit: Ich habe kürzlich offene Anfragen untersucht, die öffentlich geteilt werden, und dort viele Hardcode-Daten gesehen. Und es besteht der Verdacht, dass sich diese Daten ständig ändern. Und was soll ich sagen, am Anfang habe ich es selbst gemacht.



Durch Ausführen der Unterabfrage erhalten wir die üblichen Tickets. Als nächstes kommt die epicsOf- Funktion , die uns eine Liste der mit diesen Tickets verbundenen Epics gibt. Und dann wird nach dem Projekt gefiltert, weil ich nur Epen für mein Projekt brauche und alle anderen nicht interessant sind.



Die nächste Anfrage betrifft Epen mit Abschreibungen in diesem Jahr, aber ohne Verträge. Diese Anfrage entstand aufgrund der Tatsache, dass wir Jira nicht nur als Task-Tracker, sondern auch für die Finanzbuchhaltung verwenden. Es gibt ein separates Projekt für Verträge, das wir in Form von Tickets durchführen und das wir als elektronisches Dokumentenmanagementsystem verwenden: Der Status ändert sich ständig, wir verknüpfen Verträge mit Epen, wir wissen, wie viele Leute zu welchem ​​Epos abgeschrieben haben, wir wissen, wie viel es kostet, und dann bis Wir legen die Arbeitskosten für jeden Vertrag fest. Durch Verträge werden die Arbeitskosten auf Redmine 2.0 übertragen. Das heißt, wir schreiben in Jira ab und dann übertragen automatische Skripte unsere Kosten im Rahmen dieser Verträge an Redmine 2.0.



Als diese Automatisierung zu funktionieren begann, erhielt ich Anfragen von Kollegen dieser Art: Es gibt Epen, deren Arbeitskosten nicht auf Redmine übertragen werden können, da dort keine Verträge bestehen. Lassen Sie uns die Anfrage genauer betrachten.

issueFunction in epicsOf("worklogDate >= startOfYear()")
AND issueFunction not in hasLinkType(Contract)
AND project in (".B2G")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Die beigefügte Anfrage bedeutet, dass wir an Tickets interessiert sind, die für dieses Jahr berechnet wurden. Die Funktion epicsOf folgt aus dem vorherigen Beispiel und gibt uns eine Liste der Epen. Als nächstes wollen wir nach dem Vorhandensein von Verträgen filtern.



Der in Klammern gesetzte Vertrag ist eine Art interner Link, der Verträge mit Epen verbindet. hasLinkType () ist eine Funktion in ScriptRunner, die Tickets mit diesem Link-Typ zurückgibt. Aber ich brauche Tickets, die diese Art von Beziehung nicht enthalten, und deshalb verwende ich die Negation nicht in.



Als die erste Bedingung erfüllt war, bekam ich eine Reihe von Epen, die dieses Jahr relevant waren. Außerdem wurden Epen ohne Verträge gefiltert und im Finale - für ein bestimmtes Projekt "Video.B2G". Auf diese Weise bekam ich alle Epen, mit denen ich arbeiten konnte.



Und am Ende möchte ich vorschlagen, einen kleinen Test mit drei Fragen zum Thema dieses Beitrags zu bestehen. Wird 2 Minuten dauern. Nach dem Bestehen sehen Sie Ihre Bewertung.

Umfrage Link

Ich würde mich freuen, etwas zu klären oder Fragen in den Kommentaren zu beantworten, wenn Sie welche haben.

Vielen Dank.