Jira Automatisierung mit ScriptRunner

Wenn ich in Jira meine Tickets bearbeite und sie durch die Status schiebe, bemerke ich oft gar nicht, was im Hintergrund alles passiert – wie von Zauberhand werden Bearbeiter zugewiesen, Felder aktualisiert oder Benachrichtigungen verschickt. Mit Magie hat das natürlich nichts zu tun, sondern mit der eingebauten Automatisierung von Jira. Dank Automatisierungsregeln lassen sich Aktionen basierend auf bestimmten Ereignissen oder Bedingungen ausführen. Außerdem bieten Workflows die Möglichkeit, bei Statusübergängen Trigger, Bedingungen, Validatoren und Folgefunktionen zu nutzen, um Prozesse noch präziser zu gestalten. Dabei steht eine ganze Palette an vordefinierten, oft konfigurierbaren Funktionen zur Verfügung.

Doch was, wenn diese Standard-Automatisierungen nicht ausreichen und die Prozesse komplexer sind? Genau hier kommt der Jira ScriptRunner ins Spiel. Dieser ist ein kostenpflichtiges Add-On für Jira, welches in vielen Unternehmen genutzt wird. Mit individuellen Groovy-Skripten lassen sich Automatisierungen maßschneidern, Daten gezielt anpassen und sogar Tickets automatisch erstellen – kurz gesagt: ScriptRunner gibt Ihnen die volle Kontrolle über Ihre Jira-Prozesse.

Wie genau das in der Praxis aussieht, zeige ich Ihnen anhand konkreter Beispiele aus meinem letzten Projekt bei einem Unternehmen der Versicherungsbranche. Sie werden sehen, dass sich mit Skripten Unteraufgaben automatisch anlegen lassen, individuelle Felder befüllt werden können und sogar Tool-übergreifende Automatisierungen möglich sind. Klingt spannend? Dann legen wir los!

Das Projekt: Automatisierung Jira-Prozess für den Aufbau und Umbau von Testumgebungen

Das Ziel unseres Projekts war es, einen neuen, skript-unterstützten Prozess zur Bereitstellung von Testumgebungen zu entwickeln. Einfach gesagt sind das Rechner, auf denen bestimmte Software in einem vordefinierten Zustand läuft, damit man sie für Tests nutzen kann. Der neue Prozess sollte die Effizienz der Bereitstellung steigern, manuelle Aufwände minimieren und Fehlerquellen verringern.

Die wichtigsten Ziele des Projekts, die für diesen Artikel relevant sind, lassen sich wie folgt zusammenfassen:

• Reduzierung manueller Aufwände: Die automatische Erstellung von Unteraufgaben und das automatische Aktualisieren von Confluence-Seiten.
• Einführung von Quality Gates: Automatische Tests, um sicherzustellen, dass die bereitgestellte Umgebung korrekt ist.

Um diese Ziele zu erreichen, haben wir ein neues Jira-Projekt „Umgebungsmanagement“ angelegt. Dieses Projekt beinhaltet die Vorgangstypen „Umgebungsanforderung“ und „Umgebung“. Eine Umgebungsanforderung wird erstellt, wenn eine neue Umgebung benötigt wird, sie enthält die gewünschte Zielkonfiguration. Das Umgebungsticket repräsentiert dann die tatsächliche Testumgebung mit der aktuellen Konfiguration. Für beide Vorgangstypen wurden individuelle Workflows entwickelt.

Der Ablauf ist wie folgt: Zuerst legt ein Anforderer eine Umgebungsanforderung an und füllt diese mit wichtigen Daten wie Termin, zu installierende Software mit den zu verwendenden Software-Versionen. Danach ergänzt ein Mitarbeiter aus dem Umgebungsmanagement-Team fehlende Daten und schließt die Planung ab. Und hier kommt die Automatisierung ins Spiel: Es folgt eine automatische Prüfung auf Vollständigkeit, das Umgebungsticket wird mit den Daten aus der Umgebungsanforderung erstellt, eine neue Confluence-Seite wird (falls noch nicht vorhanden) angelegt und mit den Informationen aus dem Umgebungsticket aktualisiert. Anschließend werden die notwendigen Unteraufgaben für den Aufbau oder den Umbau der Umgebung automatisch erstellt.

Zusätzlich wurden im Projekt verschiedene Quality Gates als Jenkins-Pipelines integriert. Diese prüfen bspw., ob die richtige Software in den richtigen Versionen installiert ist oder ob Testdaten korrekt anonymisiert wurden. Über Links in den Unteraufgaben können diese Quality Gates in Jenkins aufgerufen und die Ergebnisse direkt im Umgebungsticket in Jira mit einem Ampelsystem, das den Status anzeigt, angezeigt werden.

Wie wir all das mit dem ScriptRunner umgesetzt haben, möchte ich Ihnen jetzt anhand von konkreten Beispielen zeigen. Dabei kommen Features wie Workflows, Listeners, REST Endpoints und Fields zum Einsatz.

Workflow: Validator als Pflichtfeldprüfung

Workflow-Validatoren stellen sicher, dass bestimmte Bedingungen erfüllt sind, bevor ein Statusübergang durchgeführt wird. Falls die Bedingungen nicht erfüllt sind, wird der Übergang nicht durchgeführt und eine Fehlermeldung ausgegeben, um den Nutzer darauf hinzuweisen, was korrigiert werden muss.

In unserem Projekt haben wir einen Validator entwickelt, der beim Übergang in den Status „In Arbeit“ Pflichtfelder in der Umgebungsanforderung prüft – und zwar nicht einfach nur stumpf, sondern mit einer gewissen Intelligenz. Denn es reichte nicht immer aus, einfach zu verlangen, dass alle Felder ausgefüllt sind. Manchmal hing die Pflicht eines Feldes davon ab, was in einem anderen Feld steht. Genau das macht unser Validator: Er checkt nicht nur, ob etwas eingetragen wurde, sondern auch, ob die Kombinationen sinnvoll sind.

Ein Beispiel: Es gibt einige Felder, die immer gefüllt sein müssen – etwa die Info, ob es sich um einen Aufbau oder einen Umbau handelt, welche Art von Umgebung benötigt wird oder ob die Software als Full oder Single Deployment installiert werden soll. Aber nicht jede Kombination ist erlaubt. Ein kompletter Neuaufbau der Umgebung? Dann darf es gar nicht erst die Option „Single Deployment“ geben, sondern es muss ein Full Deployment sein. Fehlt diese Angabe oder ist sie falsch gesetzt, dann blockiert der Validator den Statusübergang und gibt eine klare Fehlermeldung aus:

Workflow: Folgefunktion zur automatischen Anlage von Unteraufgaben

Workflow-Folgefunktionen sorgen dafür, dass nach einem Statusübergang automatisch bestimmte Aktionen ausgeführt werden. Sie können zum Beispiel Felder aktualisieren, Kommentare hinzufügen oder Benachrichtigungen versenden.

In unserem Projekt gab es die Anforderung, dass bei Erreichen des Status „In Arbeit“ einer Umgebungsanforderung automatisch Unteraufgaben erstellt werden. Während Jira Bordmittel einfache Unteraufgaben anlegen können, war die Logik hier so komplex, dass wir eine eigene Folgefunktion entwickeln mussten. Es ging darum, zu bestimmen, welche Unteraufgaben angelegt werden, welche Texte sie enthalten und welche Abhängigkeiten zwischen ihnen bestehen.

Dafür wurden Template-Unteraufgaben definiert. Templates enthalten vorgefertigte Texte mit Platzhaltern, die beim Erstellen der tatsächlichen Unteraufgaben automatisch durch Informationen aus der Umgebungsanforderung ersetzt werden. Zudem haben wir Bedingungen definiert, die festlegen, welche Informationen in der Umgebungsanforderung vorhanden sein müssen, damit eine Unteraufgabe erstellt wird. In den Templates konnten sogar Bilder, Anhänge und Abhängigkeiten zu anderen Templates hinterlegt werden, die bei der Erstellung der Unteraufgaben übernommen werden. Zusätzlich wurden E-Mail-Templates eingebaut, die beim Erreichen eines bestimmten Zustands einer Unteraufgabe eine E-Mail mit vordefiniertem Text versenden.

Das Skript wertet anschließend alle relevanten Informationen aus der Umgebungsanforderung und den Templates aus, erstellt die passenden Unteraufgaben, ersetzt die Platzhalter und verknüpft die Unteraufgaben gemäß den definierten Template-Verknüpfungen miteinander. Klingt kompliziert? War es auch! Aber es hat letztlich wunderbar funktioniert.

Listener: Aktualisierung der Confluence-Seite einer Umgebung

Listener in Jira ScriptRunner reagieren auf bestimmte Ereignisse, wie das Erstellen, Aktualisieren oder Ändern von Tickets. Sie ermöglichen es, automatisch Aktionen auszuführen, sobald ein definiertes Ereignis eintritt.

Ein konkretes Beispiel aus unserem Projekt ist das automatische Aktualisieren der zugehörigen Confluence-Seite, sobald ein Umgebungsticket gespeichert wird. Dies wurde umgesetzt, indem das Skript per REST-API auf Confluence zugreift. Es sucht die passende Seite anhand des im Umgebungsticket hinterlegten Umgebungsnamens. Falls die Seite noch nicht existiert, wird sie basierend auf einer Vorlage neu erstellt. Danach füllt das Skript eine Tabelle auf der Seite mit den relevanten Daten aus dem Umgebungsticket. Früher wurde diese Aufgabe manuell erledigt – eine echte Erleichterung für die Mitarbeiter.

REST Endpoints: Quality-Gate-Ergebnis aus Jenkins in Jira hinterlegen

REST Endpoints in Jira ScriptRunner bieten die Möglichkeit, maßgeschneiderte API-Endpunkte zu erstellen, die auf HTTP-Anfragen reagieren. So lässt sich eine einfache Kommunikation zwischen Jira und externen Systemen herstellen.

Dank eines solchen Endpunkts konnten wir in Jira direkt die Ergebnisse unserer Quality Gates aus Jenkins empfangen. Jedes Mal, wenn in Jenkins eine Quality-Gate-Pipeline durchläuft, wird das Ergebnis als JSON an unseren Endpunkt gesendet. Dieser speichert die Daten in einer Datei auf dem Jira-Server, die alle Quality-Gate-Ergebnisse für sämtliche Umgebungen zusammenführt. Was mit diesen Daten dann geschehen wird, ist im nächsten Abschnitt beschrieben und auch schon auf der folgenden Abbildung erkennbar.

Fields: Anzeige der Quality-Gate-Ergebnisse im Umgebungsticket

ScriptRunner Fields bieten die Möglichkeit, benutzerdefinierte Felder zu erstellen, die dynamische Werte enthalten. Diese Werte können aus Jira-Daten oder externen Quellen stammen und sogar im HTML-Format angezeigt werden.

Wir haben diese Funktion genutzt, um die Ergebnisse der Quality Gates in Jira mit einem Ampel-Symbol darzustellen. Dazu wurden zwei Felder angelegt: eines für den Gesamtstatus aller Quality Gates einer Umgebung für die Anzeige in einem Dashboard und eines für die detaillierten Ergebnisse. Die Datenbasis dafür ist die Datei, die über den REST Endpunkt erstellt wird. Der Inhalt des Detail-Feldes, wie es im Umgebungsticket auch angezeigt wird, sieht etwa so aus:

Fazit

ScriptRunner hat sich als unverzichtbares Tool für unser Umgebungsmanagement-Projekt erwiesen. Sämtliche Automatisierungen wurden mit ScriptRunner umgesetzt, von einfachen Feldern bis hin zu komplexen Workflow-Folgefunktionen.

Auch die Entwicklung der Skripte macht Spaß – sie bietet Raum für kreative Lösungen und lässt sich mit etwas Übung effizient gestalten. Wer keine Programmiererfahrung hat, kann kleinere Skripte sogar mithilfe einer KI erstellen und anpassen. Damit wird ScriptRunner nicht nur für Entwickler, sondern auch für technisch versierte Admins zu einem wertvollen Werkzeug.

Hinweise:

Wollen Sie JIRA für Ihre Projekte erweitern? Dann sprechen Sie mit uns über Ihr Projekt.

Hier finden Sie weitere Informationen zum Jira ScriptRunner.

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren beliebten Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter.