JIRA Automation - Killerfeature oder Spielerei?

Seit einer Weile (in der Server-Version als Automation for JIRA Server seit 2016) gibt es ein neues Feature, bzw. Plugin in Atlassian's JIRA (bei mir ist Cloud-Veriante im Einsatz). Es nennt sich schlicht JIRA Automation und macht seinem Namen, wie ich finde, alle Ehre. Mit diesem Plugin können Global oder auf Projektebene Automation-Regeln erstellt werden, die zu bestimmten Events (sog. Triggern) oder zeitgesteuert ausgeführt werden.  

Zwar kann JIRA out of the box schon recht viel an Automation, allerdings muss man dazu bislang immer in die tiefen der Workflows absteigen und hatte dabei ohne mächtigere Plugins wie beispielsweise Script Runner von Adaptavist auch nur einige der  Möglichkeiten, die es nun mit JIRA Automation gibt.

Das Interface ist sehr intuitiv gesaltet und eigentlich selbsterklärend. Wie man es von Services wie IFTTT, Zapier, Integromat, usw. kennt, gibt es einen "Step-By-Step"-Bereich, in dem Triggers mit Conditions und Actions aneinander gereiht werden. Es ist deutlich User-freundlicher, als das Pendant von Script Runner.

Test-Szenario zusammenbauen

Ich habe mir ein kleines Test-Szenario ausgedacht und mal flugs zusammengebaut. OK; flugs ist vielleicht etwas übertrieben, da ich doch gut eine halbe Stunde dran saß, bis ich es endlich so hatte, wie ich es mir ausdachte. Das Szenario - könnte eines aus dem echten Leben sein: ein Bug, der als Changerequest klassifiziert wurde, soll nicht geschlossen werden dürfen, wenn keine Zeitbuchung vorhanden ist. Das Ergebnis schaut wie folgt aus:  

Auf dem Bild oben: Grün ist der Trigger (wenn die Issue in den Status Done transitioned wird). Orange sind die Conditions (es muss sich um ein Issue vom Typ Bug handeln, ein Label "changerequest" muss vorhanden sein und es darf keine Zeitbuchung vorhanden sein. Hellblau sind die Actions, die durch die Automation ausgeführt werden (ein Kommentar wird hinzugefügt und die Issue zurück in den Status "In Progress" transitioned).

In Aktion schaut das ganze dann wie folgt aus. Es wird eine Issue vom Typ Bug erstellt, mit einem Label "changerequest" versehen und danach ohne Zeitbuchung in den Status "Done" geschoben. Die Automation greift, fügt den Kommentar an und schiebt die Issue wieder zurück in den Status "In Progress".  

Nitty gritty (undocumented) Details

Wie immer steckt der Teufel ja im Detail. In meinem Fall war es das Kommentarfeld. Ich wollte JIRA eine Mail an den Assignee schicken lassen, der die Zeitbuchung vergessen hat. Es gibt zwar die Möglichkeit über {{assignee.accountName}} an den Username zu kommen, doch diese wäre Plaintext und nicht in Form einer @-mention, die JIRA veranlasst eine E-Mail an die erwähnte Person zu schicken.  Die Lösung schaut wie folgt aus (und ist nicht in Atlassian's offizieller Doku zu finden.  

This is a bug which was classified as changerequest: you need to log work against this issue [~accountid:{{assignee.accountId}}].

Der wichtige Baustein ist [~accountid:{{assignee.accountId}}]. Durch ihn wird die @-mention-Funktion von JIRA getriggert. Warum ist das überhaupt wichtig? In unseren Agilen Projekten haben wir meist alle E-Mail-Benachrichtigungen Projektweit ausgeschaltet, um Ablenkungen der Devs zu minimieren; die @-mention-Funktion ist die einzige, die man nicht abschalten kann.

Mein erstes Fazit

Nach einer Weile Exploration komme ich zu dem Schluss, dass JIRA Automation mehr "Killerfeature" denn Spielerei sein wird, bzw. ist. Die Erstellung von Automations geht wirklich einfach von der Hand und es gibt eine beachtliche Menge an Trigger, Conditions und Actions, die beliebig zusammengesetzt werden können. Natürlich wird es bei der Komplexität des Systems immer wieder Dinge geben, für die man sich etwas mehr strecken und Dokumentationen oder Q&A-Foren besuchen muss, aber auch das geht im Atlassian-Kosmos vergleichsweise einfach.

Warum eigentlich "Killerfeature"? Ich denke zwar kaum, dass durch JIRA Automation wesentlich weniger Leute zu Script Runner oder Ähnlichen Addons greifen werden, allerdings wird der Lock-In durch Automation deutlich erhöht. Wendet man erst einmal die Stunden auf, die eine Einrichtung benötigt und erhält im Gegenzug Komfort, Robustheit und Zeitersparnis, dann möchte man das bestimmt nicht wieder hergeben. Man wird sich also zweimal überlegen, ob man nicht bei JIRA & Co. bleibt, bevor man in einem anderen System alles noch einmal nachbauen muss.