Wenn Sie in einem IT-Unternehmen arbeiten, basieren Ihre Prozesse höchstwahrscheinlich auf dem bekannten Atlassian-Produkt Jira. Es gibt viele Task-Tracker auf dem Markt, um dieselben Probleme zu lösen, einschließlich Open-Source-Lösungen (Trac, Redmine, Bugzilla), aber vielleicht wird Jira heute am häufigsten verwendet.

Mein Name ist Dmitry Semenikhin, ich bin Teamleiter bei Badoo. In einer kurzen Artikelserie werde ich Ihnen genau erklären, wie wir Jira verwenden, wie wir es für unsere Prozesse angepasst haben, welche guten Dinge oben „verschraubt“ wurden und wie wir den Issue Tracker zu einem einzigen Kommunikationszentrum für diese Aufgabe gemacht und unser Leben vereinfacht haben. In diesem Artikel sehen Sie unseren Ablauf im Inneren, erfahren, wie Sie Ihren Jira „drehen“ können, und lesen zusätzliche Funktionen des Tools, die Sie möglicherweise nicht kennen.

Der Artikel richtet sich in erster Linie an diejenigen, die Jira bereits verwenden, jedoch möglicherweise Schwierigkeiten haben, seine Standardfunktionen in vorhandene Prozesse im Unternehmen zu integrieren. Der Artikel kann auch für Unternehmen nützlich sein, die andere Task-Tracker verwenden, jedoch auf einige Einschränkungen gestoßen sind und eine Änderung der Entscheidung in Betracht ziehen. Der Artikel basiert nicht auf dem Prinzip der „Problemlösung“. Darin beschreibe ich die vorhandenen Tools und Funktionen, die wir rund um Jira entwickelt haben, sowie die Technologien, mit denen wir sie implementiert haben.

Zusätzliche Funktionen von Jira

Um den folgenden Text verständlicher zu machen, wollen wir herausfinden, welche Tools Jira uns für die Implementierung nicht standardmäßiger Wunschliste zur Verfügung stellt - solche, die über die Standard-Jira-Funktionalität hinausgehen.

REST-API

Im Allgemeinen ist ein API-Befehlsaufruf eine HTTP-Anforderung an eine API-URL, die die Methode (GET, PUT, POST und DELETE), den Befehl und den Anforderungshauptteil angibt. Der Anforderungshauptteil sowie die API-Antwort liegen im JSON-Format vor. Ein Beispiel für eine Anforderung, die eine JSON-Darstellung eines Tickets zurückgibt:

GET /rest/api/latest/issue/{ticket_number} 

Mit der API können Sie Skripte in jeder Programmiersprache verwenden:

• Tickets erstellen;
  
• Ändern Sie alle Eigenschaften von Tickets (integriert und benutzerdefiniert).
  
• Kommentare schreiben;
  
• Verwenden von JQL (integrierte Abfragesprache) zum Empfangen von Ticketlisten;
  
• und vieles mehr.
  

Eine ausführliche API-Dokumentation finden Sie hier .

Wir haben unseren eigenen High-Level-Jira-API-Client in PHP geschrieben, der alle erforderlichen Befehle implementiert. Hier ist ein Beispiel für Befehle zum Arbeiten mit Kommentaren:

 public function addComment($issue_key, $comment) {  return $this->_post("issue/{$issue_key}/comment", ['body' => $comment]); } public function updateComment($issue_key, $comment_id, $new_text) {  return $this->_put("issue/{$issue_key}/comment/{$comment_id}", ['body' => $new_text]); } public function deleteComment($issue_key, $comment_id) {  return $this->_delete("issue/{$issue_key}/comment/{$comment_id}"); } 

Webhooks

Mit Webhook können Sie den Aufruf einer externen Rückruffunktion auf Ihrem Host für verschiedene Ereignisse in Jira konfigurieren. Gleichzeitig können Sie so viele Regeln konfigurieren, wie Sie möchten, sodass verschiedene URLs für verschiedene Ereignisse und für Tickets, die dem im Webhook angegebenen Filter entsprechen, „zucken“. Die Webhooks-Konfigurationsoberfläche steht dem Jira-Administrator zur Verfügung.

Infolgedessen können Sie Regeln wie folgt erstellen:

Name : "SRV - Neues Feature erstellt / aktualisiert"
URL : www.myremoteapp.com/webhookreceiver
Geltungsbereich : Projekt = SRV UND Eingabe ('Neues Feature')
Ereignisse : Problem aktualisiert, Problem erstellt

In diesem Beispiel wird die angegebene URL zum Erstellen von Tickets und zum Ändern von Ereignissen aufgerufen, die dem Bereichsfilter entsprechen. Gleichzeitig enthält der Hauptteil der Anforderung alle erforderlichen Informationen darüber, was sich genau geändert hat und welches Ereignis aufgetreten ist.

Es ist wichtig zu verstehen, dass Jira nicht garantiert, dass Ihre Veranstaltung geliefert wird. Wenn die externe URL nicht geantwortet oder mit einem Fehler geantwortet hat, ist diese nirgendwo sichtbar (außer vielleicht in den Protokollen). Daher sollte der Webhook-Ereignishandler so zuverlässig wie möglich sein. Sie können beispielsweise Ereignisse in die Warteschlange stellen und versuchen, sie zu verarbeiten, bis sie erfolgreich sind. Dies hilft bei der Lösung von Problemen mit vorübergehend nicht verfügbaren Diensten, z. B. einer externen Datenbank, die für die korrekte Verarbeitung des Ereignisses erforderlich ist.

Eine ausführliche Dokumentation zu Webhooks finden Sie hier .

Scriptrunner

Dies ist ein Plugin für Jira, ein sehr leistungsfähiges Tool, mit dem Sie viele Jira anpassen können (einschließlich der Möglichkeit, Webhooks zu ersetzen). Die Verwendung dieses Plugins erfordert Kenntnisse über Groovy. Der Hauptvorteil des Tools für uns besteht darin, dass Sie benutzerdefinierte Logik online in den Ablauf einbetten können. Ihr Skriptcode wird sofort in der Jira-Umgebung als Reaktion auf eine bestimmte Aktion ausgeführt. Sie können beispielsweise eine eigene Schaltfläche in der Ticketoberfläche erstellen. Wenn Sie darauf klicken, werden Tickets erstellt, die der aktuellen Aufgabe zugeordnet sind, oder es werden Komponententests für diese Aufgabe ausgeführt. Und wenn plötzlich etwas schief geht, werden Sie als Benutzer sofort davon erfahren.

Interessenten können die Dokumentation lesen.

Flow: Was ist unter der Haube versteckt

Und nun darüber, wie wir zusätzliche Funktionen von Jira in unseren Projekten anwenden. Betrachten Sie dies im Zusammenhang mit dem Durchlaufen unseres typischen Flow-Tickets von der Erstellung bis zum Abschluss. Gleichzeitig erzähle ich Ihnen etwas über den Fluss selbst.

Open / Backlog

Das Ticket gelangt also zunächst in den Rückstand neuer Tickets mit dem Status " Offen ". Darüber hinaus trifft der Komponentenleiter, der ein neues Ticket in seinem Dashboard gesehen hat, eine Entscheidung: Weisen Sie dem Entwickler sofort ein Ticket zu oder senden Sie es an das Backlog bekannter Tickets ( Backlog- Status), damit Sie es später zuweisen können, wenn ein kostenloser Entwickler erscheint und Tickets mit höherer Priorität geschlossen werden. Dies mag seltsam erscheinen, da es logisch erscheint, das Gegenteil zu tun: Tickets im Backlog- Status erstellen und dann in den Open-Status übersetzen. Aber genau dieses Schema haben wir verwurzelt. Sie können Filter einfach konfigurieren, um die Entscheidungszeit für neue Tickets zu verkürzen. Ein Beispiel für einen JQL-Filter, der neue Aufgaben für einen Lead anzeigt:

Project = SRV AND assignee is EMPTY AND status in (Open)

In Bearbeitung

Wenn ein Ticket den Entwickler trifft, zerlegt er es als erstes. Das Ergebnis der Zerlegung ist die Idee des Entwicklers, wie das Problem gelöst werden kann und wie lange die Lösung dauern wird. Nachdem alle wichtigen Details geklärt wurden, wird das Ticket in den Status " In Bearbeitung" versetzt und der Entwickler beginnt mit dem Schreiben von Code.

Es ist üblich, dass wir das Fälligkeitsdatum für die Aufgabe zu dem Zeitpunkt festlegen, zu dem sie in den Status "In Bearbeitung" versetzt wird. Wenn der Entwickler dies nicht getan hat, erhält er eine Erinnerung im HipChat Corporate Messenger. Alle zwei Stunden ein spezielles Skript:

• Bei Verwendung der Jira REST-API werden Tickets im Status "In Bearbeitung" mit einem leeren Feld für das Fälligkeitsdatum ausgewählt ( Projekt = SRV UND Status = "In Bearbeitung" UND Duedat ist LEER ).
  
• wählt unvollständige Tickets mit einem Fälligkeitsdatum aus, das älter als das aktuelle Datum ist ( Projekt = SRV UND Status = 'In Bearbeitung ' UND duedate ist nicht leer UND duedate <now () );
  
• erkennt den Entwickler für jedes Ticket, indem er das entsprechende Feld im Ticket sowie den Lead des Entwicklers liest;
  
• gruppiert Tickets von Entwicklern und Leads und sendet mithilfe der API Erinnerungen an HipChat.
  

Nachdem der Entwickler alle erforderlichen Festschreibungen vorgenommen hat, schiebt er den Zweig in eine gemeinsame Rübe. In diesem Fall wird der Git-Hook nach dem Empfang ausgelöst, was viele interessante Dinge bewirkt:

• Der Name des Git-Zweigs sowie Kommentare zu Commits werden auf Übereinstimmung mit unseren Regeln überprüft.
  
• Es wird überprüft, ob das Ticket, dem die Filiale zugeordnet ist, nicht geschlossen ist (Sie können keinen neuen Code in geschlossene Tickets übertragen).
  
• Die Syntax der geänderten PHP-Dateien wird überprüft (PHP -l Dateiname.php );
  
• Formatierung ist aktiviert;
  
• Befindet sich das Ticket, in das die Filiale verschoben wird, im Status " Offen ", wird es automatisch in den Status " In Bearbeitung " versetzt.
  
• Das Ticket wird an die Zweigstelle angehängt. Der entsprechende Eintrag erfolgt über die Jira-API im benutzerdefinierten Feld des Commits- Tickets. Es sieht so aus:
  

( branchdiff ist ein Link zu diff des Zweigs mit dem Kopf, von dem der aktuelle Zweig in unserem Codeisok-Codeüberprüfungstool stammt.)

• Im Ticket wird ein Kommentar mit allen Commits in diesem Push erstellt.
  
  
  
  (Aida ist der bedingte Name unseres Automatisierungskomplexes für die Arbeit mit Jira, Git und nicht nur. Von diesem Namen aus erscheinen automatische Kommentare im Ticket. Wir haben im Artikel mehr über Aida geschrieben.)
  Ein Klick auf den Hash des Commits öffnet diff mit der vorherigen Revision des Zweigs (ich werde unten zeigen, wie es aussieht);
  
• Es wird geprüft, ob sich in der Verzweigung Dateien befinden, für die möglicherweise eine Übersetzung in unterstützte Sprachen erforderlich ist (z. B. Webseitenvorlagen). Wenn solche vorhanden sind, wird der neue Wert \ Geändert auf das benutzerdefinierte Feld des Lexems-Tickets gesetzt. Dies stellt sicher, dass das Ticket ohne eine vollständige Übersetzung nicht in Produktion geht.
  
• Der Name des Mitarbeiters, der den Zweig pusht, wird der Liste der Entwickler hinzugefügt (ein benutzerdefiniertes Feld des Entwicklertickets ).
  

Bei Überprüfung

Nachdem der Code geschrieben und sichergestellt wurde, dass alle Anforderungen für die Aufgabe erfüllt sind und die Tests nicht unterbrochen wurden, weist der Entwickler dem Prüfer ein Ticket zu (Status " Bei Überprüfung "). In der Regel entscheidet der Entwickler, wer sein Ticket überprüft. Höchstwahrscheinlich wird es ein anderer Entwickler sein, der sich mit dem richtigen Teil des Codes auskennt. Die Überprüfung erfolgt mit dem Codeisok- Tool, das sofort mit dem gewünschten Diff geöffnet wird , indem Sie auf den Branchdiff- Link im Feld Commits- Ticket oder auf den Kommentar als Commit-Hash in den Kommentaren klicken.

Der Rezensent sieht ungefähr so:


Nach Abschluss der Überprüfung drückt der Prüfer auf die Schaltfläche Fertig stellen. In diesem Moment geschieht unter anderem Folgendes:

• Mithilfe der JIra-API wird im Ticket ein Kommentar mit Kommentaren des Überprüfers im Kontext des Codes erstellt. Es sieht ungefähr so ​​aus:
  

• Wenn der Code kommentiert wurde und der Prüfer beschlossen hat, das Ticket erneut zu öffnen, erhält der Entwickler eine Benachrichtigung in HipChat (dies erfolgt mithilfe der Webhook-Regel, die beim erneuten Öffnen funktioniert).
  
• Das Feld für das Reviewers- Ticket wird ausgefüllt.
  

Gelöst

Wenn die Überprüfung erfolgreich war, wird das Ticket im Status " Gelöst" an den Rückstand der QS-Ingenieure gesendet. Gleichzeitig werden mithilfe von Webhook für das aufgelöste Ereignis automatische Tests des Zweigcodes im Hintergrund gestartet. Nach einigen Minuten erscheint im Ticket ein neuer Kommentar, der Sie über die Testergebnisse informiert.



Sie können auch jederzeit manuell einen wiederholten Testlauf starten, indem Sie im Ticketmenü auf die Schaltfläche "Unit Unit Tests testen" klicken. Nach einem erfolgreichen Lauf wird im Ticket ein neuer Kommentar angezeigt, ähnlich dem vorherigen.


Tatsächlich ist diese Schaltfläche einer der zusätzlichen Aufgabenstatus im Jira-Workflow, eine Übersetzung, in die ein Groovy-Skript für das ScriptRunner-Plugin ausgelöst wird. Das Skript ruft eine externe URL auf, die den Testlauf initiiert. Wenn die URL erfolgreich geantwortet hat, kehrt das Ticket zu seinem vorherigen Status zurück (in unserem Fall " Gelöst" ).

In Shot / In Shot - OK

Die Aufgabe wird zunächst in einer Entwicklungsumgebung getestet. Wenn alles in Ordnung ist, wird ein Schuss erstellt (z. B. durch Klicken auf den Link Schuss erstellen im Feld Commits ) - das Verzeichnis auf dem dedizierten Server, in das Änderungen aus dem Ticket kopiert werden, die neben dem aktuellen Master liegen. Der Server arbeitet mit Produktionsdaten: Die Datenbanken und Dienste sind dieselben, die echte Benutzer bedienen. Auf diese Weise kann der Tester eine Website öffnen oder mithilfe eines mobilen Clients eine Verbindung zum Shot herstellen und die Funktion in der Produktionsumgebung "isolieren". "Isoliert" bedeutet, dass kein anderer Code / keine andere Funktionalität außer dem neuen aus dem Zweig und dem aktuellen Master ausgeführt wird. Daher ist diese Testphase möglicherweise die wichtigste, da der QS-Techniker das Problem am zuverlässigsten direkt im Testproblem finden kann.

Auf Shot-Ressourcen wird über spezielle URLs zugegriffen, die im Shot-Erstellungsskript generiert und mithilfe der Jira-API im Ticket-Header platziert werden. Als Ergebnis sehen wir Links zu der Site, dem Admin-Bereich, Protokollen und anderen Tools, die in einer Shot-Umgebung ausgeführt werden:



Außerdem wird zum Zeitpunkt der Shot-Generierung ein Skript gestartet, das den Inhalt der geänderten Dateien analysiert und Anforderungen für die Übersetzung der gefundenen neuen Token erstellt. Nach Abschluss der Übersetzung wird der Wert des Lexems- Felds in "Fertig" geändert und das Ticket kann dem Build hinzugefügt werden.

Wenn der Test in Shot erfolgreich war, wird das Ticket in den Status In Shot - OK versetzt.

In Build / In Build - OK

Wir laden den Code zweimal täglich hoch - morgens und abends. Zu diesem Zweck wird ein spezieller Build-Zweig erstellt, der schließlich mit dem Master zusammengeführt und „im Kampf“ angelegt wird.

Zum Zeitpunkt des Erstellens des Build-Zweigs empfängt ein spezielles Skript, das eine JQL-Abfrage verwendet, eine Liste von Tickets im Status In Shot - OK und versucht, sie im Build-Zweig einzufrieren, wenn alle folgenden Bedingungen erfüllt sind:

• Die Übersetzung für das Ticket ist abgeschlossen oder es muss nichts übersetzt werden ( Lexems in ('Nein', 'Fertig') ).
  
• Der Entwickler ist am Arbeitsplatz anwesend (das automatische Fusionssystem prüft auf der internen Basis, ob sich der Entwickler im Urlaub oder im Krankheitsurlaub befindet. In diesem Fall kann das Ticket nur manuell von Release-Ingenieuren oder einem anderen verantwortlichen Entwickler eingefroren werden, was im speziellen Feld Vize-Entwickler angegeben ist ; der Anführer des abwesenden Entwicklers erhält in diesem Fall eine Benachrichtigung, dass das Ticket nicht automatisch zum Build hinzugefügt werden kann);
  
• Für das Ticket ist das Flag " Up in Build" vom Entwickler nicht gesetzt (dies ist ein spezielles benutzerdefiniertes Feld des Tickets, mit dem der Entwickler bestimmen kann, wann das Ticket zum Build gesendet wird).
  
• Die Ticketfiliale hängt nicht von einer anderen Filiale ab, die den Master oder den aktuellen Build noch nicht erreicht hat. Wir tun unser Bestes, um eine solche Situation zu vermeiden. Manchmal geschieht dies jedoch, wenn der Entwickler seine eigene Filiale nicht vom Master, sondern von einer Filiale eines anderen Tickets erstellt oder wenn er eine andere Filiale für sich selbst einfriert. Dies kann auch zufällig geschehen, daher haben wir beschlossen, dass zusätzlicher Schutz nicht schaden würde.
  

Es ist zu beachten, dass aufgrund eines Zusammenführungskonflikts möglicherweise keine automatische Zusammenführung erfolgt. In diesem Fall wird das Ticket automatisch in den Wiedereröffnungsstatus versetzt und dem Entwickler zugewiesen, über den er sofort eine Benachrichtigung in HipChat erhält, und dem Ticketkommentar wird eine entsprechende Nachricht hinzugefügt. Nach der Lösung des Konflikts kehrt das Ticket zum Build zurück.

Wenn alles in Ordnung ist und der Ticketzweig im Build eingefroren ist, wird das Ticket automatisch in den Status In Build übertragen , und der Name des Builds wird in das benutzerdefinierte Feld des Build_Name- Tickets geschrieben.


Mit diesem Wert ist es außerdem einfach, eine Liste der Tickets zu erhalten, die mit jedem Build veröffentlicht wurden. Zum Beispiel, um nach jemandem zu suchen, der die Schuld trägt, wenn etwas schief gelaufen ist.

In der nächsten Phase prüfen die QS-Ingenieure zusätzlich, ob der Aufgabencode in Verbindung mit anderen Aufgaben im Build ordnungsgemäß funktioniert. Wenn alles in Ordnung ist, wird das Ticket manuell auf In Build - OK gesetzt.

In Produktion / In Produktion - OK / Geschlossen

Während des Builds wird unser gesamter Testsatz ausgeführt (Einheit, Integration, Selen usw.). Wenn alles in Ordnung ist, wird der Build im Master eingefroren und der Code für die Produktion ausgelegt. Das Ticket wird in den Status On Production versetzt.

Außerdem stellt der Entwickler (oder der Kunde) sicher, dass die Funktion in der Produktion ordnungsgemäß funktioniert, und setzt den Ticketstatus In der Produktion - OK.

Nach zwei Wochen werden Tickets im Status On Production - OK automatisch in den Status Closed versetzt , wenn dies zuvor noch nicht manuell durchgeführt wurde.

Erwähnenswert sind auch zusätzliche Status, in denen sich das Ticket befinden kann:

• Anforderungen - Wenn es nicht möglich ist, vom Kunden schnell die erforderlichen Erläuterungen zur Aufgabe zu erhalten, und ohne sie keine weiteren Arbeiten am Ticket möglich sind, wird das Ticket in diesen Status versetzt und demjenigen zugewiesen, der Erklärungen abgeben muss.
  
• Angehalten - Wenn die Ticketarbeit unterbrochen wird, z. B. wenn der Entwickler durch Aufgaben eines benachbarten Teams blockiert ist oder zu einer dringenderen Aufgabe wechseln musste.
  
• Wiedereröffnet - Eine Aufgabe kann nach einer Überprüfung, nach dem Testen und nach einem erfolglosen Versuch, einen Zweig mit dem Master zusammenzuführen, für den Entwickler wiederentdeckt werden.
  

Infolgedessen sieht ein vereinfachtes Diagramm unseres Workflows folgendermaßen aus:

Ticket - Kommunikationszentrum für die Aufgabe

Durch das Weiterleiten des Tickets durch den Flow erhält sein Header ungefähr die folgende Form:



Was ist hier noch interessant, das wir für uns angepasst haben und das ich noch nicht erwähnt habe?

• Komponente - wird verwendet, um ein Ticket innerhalb einer großen Abteilung zu gruppieren. Verschiedene Untergruppen sind für verschiedene Komponenten verantwortlich und sehen in ihren Dashboards dementsprechend nur Aufgaben für ihre Komponenten. Zum Beispiel kann ich mit dieser Abfrage alle offenen Fehler für die Komponenten meines Teams auflisten:
  
  

   Project = SRV AND type = Bug AND status = Open AND component in componentsLeadByUser(d.semenihin) 

  
  
• Überprüfung - ob eine Codeüberprüfung erforderlich ist. Standard ist erforderlich. Wenn der Feldwert auf Nein gesetzt ist, erhält das Ticket sofort den Status " Gelöst " .
  
  QA - Muss der Tester überprüft werden? Standard ist erforderlich. Wenn der Feldwert auf Nein gesetzt ist, wechselt das Ticket sofort in den Status In Shot - OK.
  
  Sprint - in unserem Fall ist er nur für Aufgaben mit dem Typ "Neues Feature" relevant, für die wir eine Woche im Voraus einen Plan erstellen.
  
• Fälligkeitsdatum - Der Entwickler bestimmt das Datum, an dem das Ticket produziert wird. Vor Beginn der Arbeit an der Aufgabe ausgestellt.
  
• Situation - in der Tat ein kurzes Protokoll mit einer kurzen Beschreibung des aktuellen Status der Aufgabe. Beispiel: "20/08 Ich warte auf Übersetzungen" , "21/08 Klärung des Kunden zu Problem X" . Dies hilft, eine kurze Zusammenfassung der Aufgabe in der Liste der anderen Aufgaben zu sehen.
  
• Msg4QA - Informationen für QS-Ingenieure, die der Entwickler zur Vereinfachung des Testprozesses weitergibt
  

Wir versuchen, mit dem Task Director in den Kommentaren des Tickets eine Diskussion über kontroverse Themen zu führen und wichtige Klarstellungen nicht per Post und Instant Messenger zu "verschmieren". Wenn die Diskussion dennoch "nebenbei" stattgefunden hat, ist es äußerst wünschenswert, das, was Sie vereinbart haben, in das Ticket zu kopieren.

Zusätzlich zu "menschlichen" Texten, wie ich oben erwähnt habe, werden viele Dinge automatisch in einem Kommentar unter Verwendung der API geschrieben:

• begeht
  
• Ergebnisse überprüfen;
  
• Testergebnisse.
  

Manchmal können automatische Kommentare beispielsweise Produktmanager stören. Aus diesem Grund haben wir ein einfaches JS-Skript erstellt, das der Jira-Oberfläche eine Schaltfläche hinzufügt und es Ihnen ermöglicht, alle automatischen Kommentare zu minimieren, sodass nur menschliche Kommentare übrig bleiben. Minimierte automatische Kommentare wirken daher kompakt.

Was sonst?

API webhooks Jira :

• HipChat, - ( );
  
• HipChat ( , );
  
• ( ) ( ; );
  
• ; , ;
  
• In progress ;
  
• , «» (, On Review), ;
  
• , Jira (, «d.semenihin (Day off)»). .
  

Zusammenfassung

Jira — , , . , , . Jira , .

— . Jira , Jira. , - .

Vielen Dank für Ihre Aufmerksamkeit!