Selbständiger IT-Berater und Trainer. 10 Jahre Erfahrung in der Beratung und Schulung von Jira Automation: Best Practices – Teil 1
Eine der häufigsten Anforderungen an eine Vorgangsverwaltung ist die Automatisierung von Arbeitsschritten. Jira war dabei mit Bordmitteln bisher leider nur schwach ausgestattet, was den Rückgriff auf Apps wie „Automation for Jira“ zur Folge hatte. Während Nutzerinnen und Nutzer von Jira Data-Center diese App auch weiterhin kostenpflichtig erwerben können, ist sie in der Cloud-Variante zum standardmäßigen Funktionsumfang geworden. Damit steht prinzipiell ein äußert mächtiges Werkzeug zur Verfügung, bei dessen Verwendung allerdings einige Regelungen beachten werden müssen, die deutliche finanzielle Auswirkungen haben können. Im ersten Teil der Jira Automation Best Practices soll es also um die Anzahl der Regelausführungen sowie den geeigneten Einsatz von Triggern gehen.
Dieser Artikel bezieht sich ausschließlich auf die Cloud-Variante von Jira. In der Server- und Data-Center-Variante ist die App „Automation for Jira“ kostenpflichtig und keine Begrenzung von Regelausführungen vorhanden.
Bei der Planung von Automatisierungen sollte beachtet werden, dass je nach verwendetem Cloud-Tarif nur eine begrenzte Anzahl an Regelausführungen möglich ist. Konkret heißt das, dass im Free-Tarif nur 100 und im Standard-Tarif nur 500 monatliche Ausführungen globaler- bzw. projektübergreifender Regeln möglich sind. Im Premium-Tarif sind pro lizensierter Person 1.000 monatliche Ausführungen möglich. Im Enterprise-Tarif sind keine Limitierungen vorhanden. (Quelle)
Mit globalen- bzw. projektübergreifenden Regeln sind dabei diejenigen Regeln gemeint, welche im verwendeten Trigger oder in der ausgelösten Aktion mehrere Projekte umfassen. Ein vereinfachtes Beispiel für eine projektübergreifende Regel: wird im Support-Projekt ein Ticket kommentiert, wird dieser Kommentar automatisch in einen verlinkten Vorgang eines internen Projektes kopiert. Diese Regel umfasst zwei verschiedene Projekte und zählt damit bei jedem Auslösen des Triggers in das monatliche Budget.
Ausnahme: das projektübergreifende Erstellen von Vorgängen (Bsp.: ein Statusübergang „Weitergabe an internen Support“ erzeugt automatisch einen Vorgang in einem anderen Projekt) zählt nicht in das monatliche Budget.
Bei der Berechnung der Anzahl von Regelausführungen ist zu beachten, dass nicht das Auslösen einer Aktion, sondern bereits das Auslösen des Triggers als Regelausführung gezählt wird (z.B. Vorgang erstellt, Vorgang bearbeitet), selbst wenn letztendlich keine Aktion durch die Regel ausgelöst wird. Regeln, welche ausschließlich innerhalb eines einzigen Projektes stattfinden (sowohl Trigger als auch Aktion) sind in allen Tarifen unbegrenzt durchführbar. (Quelle)
Trigger sollten als grundsätzlich (mindestens aber im Free- und Standard-Tarif) so konzipiert werden, dass diese möglichst selten ausgelöst werden. Ein Beispiel: beim Wiedereröffnen eines Support-Tickets im Service Management soll ein verknüpfter Bug in einem internen Projekt ebenfalls erneut geöffnet werden. Es handelt sich also um eine projektübergreifende Regel, deren Trigger auf Ereignisse in beiden Projekten reagiert.
Ein vereinfachtes Negativ-Bespiel:
Dieser Trigger wird bei jedem Statusübergang in einem der beiden Projekte ausgelöst. Erst danach wird über JQL abgefragt, welcher Statuswechsel eine Aktion auslösen soll. Hier ist also potenziell mit sehr vielen Regelauslösungen zu rechnen, da bereits das Triggern der Regel als Ausführung zählt.
Dieselbe Regel, diesmal mit besserem Trigger:
Diese Regel wird nur beim relevanten Statusübergang (von „Geschlossen“ zu „Erneut geöffnet“) ausgelöst und spart dadurch ggf. sehr viele Ausführungen. Sollte dieser Statusübergang nur im Workflow der Support-Tickets und nicht im Workflow der internen Bugs vorhanden sein, spart man weitere Ausführungen und könnte die JQL-Abfrage „project = Support“ theoretisch auch weglassen.
Tipp 1: häufig soll beim Schließen eines Vorgangs eine Aktion ausgelöst werden. In diesem Fall bietet es sich an, nicht einen bestimmten Statusübergang, sondern das Setzen einer Lösung als Trigger zu verwenden. Dadurch ist man bei eventuellen Änderungen am Workflow flexibler. Auch im obigen Beispiel könnte man alternativ das Entfernen der Lösung als Trigger verwenden.
Tipp 2: eine Übersicht über das monatliche Kontingent von Regelausführungen erhält man in Jira unter „System – Automation Rules – Nutzung“. Im Bild sind 500 Ausführungen aus dem Jira Standardtarif und 100 Ausführungen aus dem Service-Management Free-Tarif enthalten.
