Automatisierung und Effizienzsteigerung mit Hilfe von Scriptrunner für Jira – Teil 1

Als Jira Systemadministrator ist man immer wieder mit der Herausforderung konfrontiert, dass nach Möglichkeiten der Produktivitätssteigerung gefragt wird.

Hierfür gibt es viele Beispiele:

• Der Projektleiter wünscht sich Automatismen im Arbeitsablauf, um dem Anwender manuelle Eingriffe abzunehmen und so das Projekt effizienter durchführen zu können.
• Der Projektleiter wünscht sich komplexere Berechtigungen, um bestimmte Arbeitsabläufe zu beschränken.
• Der Anwender braucht komplexe Filter, um Vorgänge einfacher strukturieren zu können.
• Nicht zuletzt hat auch der der Administrator selbst das Bedürfnis nach Automatisierung, um bestimmte Vorgänge nicht immer wieder manuell durchführen zu müssen.

Diese Liste lässt sich mit Sicherheit noch fast endlos fortsetzen.

In diesem Beitrag möchten wir euch einen Überblick geben, wie Scriptrunner für Jira hier an der einen oder anderen Stelle hilfreich eingesetzt werden kann.

Die Scriptrunner-Module

Scriptrunner besteht aus Modulen – verschiedenen Funktionalitäten, die alle auf der Scriptengine basieren. Letztendlich können alle diese Module, abseits der Grundfunktionalitäten zur Erweiterung des Basis-Jira, richtig angewendet eine Steigerung der Produktivität bewirken. In diesem Beitrag werden wir uns auf einige Module beschränken, die typischerweise zur Effizienzsteigerung eingesetzt werden.

Auf der linken Seite findet ihr nun untereinander aufgelistet die Scriptrunner-Module.

Über den Inhalt der einzelnen Menüpunkte findet ihr in unserem Blogbeitrag hier eine kurze Übersicht. Im heutigen  Blog wollen wir vor allem auf diejenigen Module eingehen, die uns durch standardmäßig von Scriptrunner mitgelieferte Skripte zum einen das tägliche Arbeiten erleichtern, zum anderen einfache und effektive Ansätze zur Automatisierung von Abläufen liefern.

JQL-Functions

JQL-Functions sind Erweiterungen der Jira-eigenen Abfragesprache JQL (Jira Query Language), die die Basis aller Anzeigen von Vorgängen darstellt. Wann immer in Jira ein oder mehrere Vorgänge angezeigt werden, sei es auf Boards, in Filtern oder aber auch in externen Systemen, wie z.B. Confluence, wird der Inhalt der Anzeige durch eine JQL-Abfrage erzeugt. Mit der Installation von Scriptrunner für Jira erweitert ihr die ohnehin schon umfangreiche Funktionsbibliothek von Jira um diverse nützliche Funktionen.

Die von Jira mitgelieferten, zusätzlichen JQL-Functions sind sinnvolle Erweiterungen, die euch die eigene Entwicklung und die Eingabe komplexer Abfragen deutlich erleichtern. Ihr erreicht eine thematisch strukturierte Auflistung über den entsprechenden Link in der o.a. Modulnavigation.

Verwenden könnt ihr diese Funktionen an jeder Stelle im System, in der JQL benutzt werden kann. Als sehr hilfreich haben sich die mitgelieferten Funktionen z.B. bei der Erstellung von komplexen Filtern und der Verwendung in mitgelieferten oder eigenen Skripten erwiesen. Da eine detaillierte Beschreibung jeder einzelnen der vielen mitgelieferten Funktionen den Rahmen dieses Blogs sprengen würde, verweisen wir an dieser Stelle gerne auf die offizielle Scriptrunner-Dokumentation zu diesem Thema.

Built-In Scripts

Die Built-In Scripts sind eine Sammlung von standardmäßig mitgelieferten Scripten, die uns die täglichen Aufgaben als Administrator erleichtern. Diese Scripte sind für die direkte Ausführung gedacht und können typische Administrationsaufgaben und Anforderungen mit nur geringem Konfigurationsaufwand erledigen.

Ein kurzes Beispiel

Log Files

Ein kurzer Blick in die Logs ist notwendig, weil ein Anwender sich mit einem Problem gemeldet hat? Ein Klick auf „View Server Log Files“ öffnet eine Maske, in der Ihr nur noch angeben müsst, welches Logfile ihr einsehen wollt und wie viele Zeilen in der Anzeige vorhanden sein sollen (dies sind jeweils die letzten X Zeilen des Logs):

Mit „Run“ wird euch dann direkt darunter das Ergebnis angezeigt:

Die meisten der Built-In Scripts sind durch ihren Namen selbsterklärend und zudem sind alle Scripts in der Übersicht kurz beschrieben. Habt ihr weitere Fragen zu diesen Skripten, so scheut euch bitte nicht, diese in den Kommentaren zu stellen.

Behaviours

Behaviours dienen dazu, Felder bestimmte Eigenschaften zuzuweisen, die im Standard nur schwer abzubilden oder unter Umständen gar nicht möglich sind. Zum Beispiel kann man mittels Behaviours auch die Standardwerte von Systemfeldern beeinflussen.

Als einfaches Beispiel für ein Behaviour wollen wir hier einmal annehmen, dass folgende Anforderung an uns herangetragen wurde:

In unserem Projekt können Projekt-Leiter und Entwickler jederzeit eine Story anlegen. Während Projekt-Leiter das zu Planungs- und Vorbereitungszwecken auch im Voraus ohne Bezug zu einem existierenden Epic machen können, dürfen Entwickler dies nur im Bezug zu einem bereits bestehenden Epic.

Zusammengefasst: Beim Anlegen eines Vorganges vom Typ „Story“ soll das Feld „Epic-Verknüpfung für alle Benutzer außer dem Projektleiter (Project lead) ein Pflichtfeld sein.

Zur Umsetzung der Anforderung entscheiden wir uns zur Nutzung von Behaviours. Nach einem Klick auf „Behaviour“ sehen wir folgende Maske:

Hier geben wir einen Namen und optional eine Beschreibung für unser Behaviour an und klicken auf „Add“. Die Behaviour ist nun grundsätzlich angelegt, nun müssen wir sie „mit Leben füllen.

Im ersten Schritt fügen wir ein „Mapping“ hinzu, das heißt wir definieren, in welchem Kontext das Behaviour gelten soll. Hierzu klicken wir zunächst rechts neben unserer neuen Behaviour aus das Zahnradsymbol und wählen „Add Mapping“:

In dem nun erscheinenden PopUp können wir definieren, für welche(s) Projekt(e) und welche(n) Vorgangstypen unsere neue Behaviour gelten soll:

In unserem Fall also den Namen des betroffenen Projektes und den Vorgangstyp „Story“.

Nun enthält die Listenansicht unser neues Behaviour mit Angabe des Mappings aber immer noch ohne Funktion. Um diese hinzuzufügen, klicken wir wiederum auf das Zahnradsymbol und wählen diesmal den Punkt „Edit“.

In dieser Maske definieren wir nun die eigentliche Funktionalität:

• Use Validator Plugin
  • Soll bei Verwendung der separaten Jira-App „Jira Script Utlilities“ der Kennzeichner „Pflichtfeld“ gesetzt werden?
• Guide workflow
  • In welchem Workflow soll das Behaviour greifen?
  • Diese Einstellung ist notwendig, wenn in den Bedingungen für das Behaviours auf Aktionen, Rollen und Namen zugegriffen werden soll. In unserem Fall also den passenden Workflow für unser Projekt auswählen.
• Initialiser
  • Der Initialisierer arbeitet einmalig, wenn zum Bespiel das betroffene Feld in einem Formular angezeigt wird. Hier kann also z.B. ein Standardwert gesetzt werden.
  • In unserem Beispiel wird er nicht benötigt.
• Add Field
  • Hier wählen wir aus der Liste das Feld, für das das Behaviour gelten soll.
  • In unserem Beispiel wählen wir „Epic-Verknüpfung“ aus der Liste. Und klicken auf „Add“

Nun sehen wir folgende Ergänzung der Maske:

Hier definieren wir nun die Funktionen unseres Behaviours:

• Optional
  • Das Umschalten macht aus dem Feld ein Pflichtfeld.
  • Das ist genau die Funktionalität, die wir haben wollen also setzen wir es.
• Writeable
  • Soll das Feld beschreibbar sein?
• Shown
  • Soll das Feld angezeigt werden?
• Add new condition.
  • Öffnet ein PopUp, in dem wir die Bedingungen für das Behaviour definieren können.
  • Es werden verschiedene Optionen angeboten
  • Wir wählen die Kombination, die bewirkt, dass die Behaviour NICHT greift, wenn der aktuelle Benutzer in der Rolle des Projektleiters ist:

Ein Klick auf „Add“ fügt die Bedingung unserm Behaviour hinzu.

Die vollständige Behaviour sieht nun so aus:

Mit einem Klick auf Save wird das Behaviour endgültig gespeichert.

In dieser Maske, die in der Behaviour-Liste jederzeit über „Edit“ aufgerufen werden kann, können auch jederzeit Felder Bedingungen hinzugefügt, angepasst oder entfernt werden, falls dies notwendig sein sollte. Über den Punkt „Add server-side script“ können darüber hinaus auch Bedingungen in Form von auf dem Server hinterlegten Scripten in Groovy-Dateien genutzt werden.

Das war es für diesen Beitrag zum Thema Automatisierung mit Scriptrunner. In naher Zukunft erscheint auch Teil 2 dieses Beitrages, in dem es vor allem um die Themen Listener, Jobs und REST gehen wird.

Wenn es euch gefallen hat oder ihr Fragen oder Anregungen habt, dann hinterlasst gerne einen Kommentar.