Ein interessantes neues, bisher aber weitgehend unbeachtetes Feature von Atlassian JIRA 6.3 ist das Automatisieren von Übergängen innerhalb von JIRA Workflows. Ein JIRA-Workflow beschreibt eine Sammlung aus mehren Status (Statuses) und Übergängen (Transitions), welche ein JIRA-Vorgang im Rahmen seines Lebenszyklus durchläuft, z.B. Offen / In Bearbeitung / Gelöst / Geschlossen.

Mussten Entwickler bisher daran denken, nach einem Commit oder Öffnen eines Pull Requests den dazugehörigen JIRA-Vorgang entsprechend zu aktualisieren, lassen sich Übergänge nun auch via Trigger-Ereignissen auslösen. Der Vorteil liegt auf der Hand: Entwickler können sich auf das Wesentliche konzentrieren, Team-Mitglieder und Projektbeteiligte werden in Echtzeit über Änderungen informiert. Dadurch bleiben die Metriken stets aktuell, was Projektleiter zu präziseren Vorhersagen bezüglich Lieferterminen oder Engpässen verhilft.

Automatisierungs-Trigger im Überblick

Ein JIRA-Trigger lauscht auf ein Ereignis innerhalb von JIRA, an durch Application Links verknüpfte Projekte weiterer Atlassian-Werkzeugen oder Third-Party-Schnittstellen und löst entsprechend eine Änderung des Zustands des Vorgangs aus. So kann beispielsweise ein Vorgang automatisch als In Bearbeitung markiert werden sobald ein Smart Commit mit der entsprechenden Issue-ID getätigt wurde.

JIRA Workflow Automation Trigger

Automatisierungs-Trigger sind lediglich ein weiteres Werkzeug um den Status eines Vorgangs zu verändern. Es ist immer noch möglich die entsprechenden Knöpfe an Vorgang zu verwenden oder auf einem Agile Board zu verschieben. Voraussetzung für den Einsatz von Triggern mit Atlassian-Werkzeugen sind Stash ab Version 3.2 und FishEye + Crucible ab Version 3.5.

Ein praktisches Beispiel: Git Workflow

Interessante Ereignisse für JIRA-Workflows rund um Software-Entwicklung mit Stash (oder Git Hub, Bitbucket, …) und einem komplexen Git Workflow wie Git Flow sind Commit Created-, Branch Created– sowie alle Pull Request-Trigger.

Betrachten wir also einen exemplarischen Workflow in JIRA, welchen wir mit Git Flow und Stash verknüpfen wollen:

JIRA Sample Workflow

Hier eröffnen sich zahlreiche Ansätze für eine mögliche Automatisierung:

  • Erstellung eines neues Feature-Zweiges
  • Pull Request eines Entwickler
  • Den Prozess rund um Code Reviews, bspw. Pull Request abgelehnt oder Verbesserungen eingespielt
  • Abschluss der Feature-Entwicklung; Pull Request akzeptiert und in den Hauptzweig gemerged

Diese Übergänge und mögliche Trigger wollen wir anhand eines kleinen Beispiels exemplarisch betrachten.

Neuer Zweig erstellt

Erstellt ein Entwickler einen neuen Feature-Zweig für einen Vorgang, lässt sich dieser automatisch von Open nach In Progress überführen dank des Branch Created Triggers.

JIRA Stash Create Branch Workflow

Zusätzlich kann man mit dem Commit Created-Trigger auf Änderungen an den Hauptzweigen lauschen (oder eine klassische, Mainline-basierte Entwicklung stützen).

Pull Requests

Möchte ein Entwickler wiederum seinen Feature-Zweig in den Hauptzweig integrieren, so öffnet er einen Pull Request. Der Pull Request Created-Trigger löst hier automatisch einen Übergang nach In Review aus. Wird der Pull Request abgelehnt, helfen die Pull request declined oder Review rejected-Trigger, den Vorgang wieder nach In Progress zu überführen.

In Review Combo Trigger

Merge-Vorgang

Wird das Feature angenommen, so lässt sich der Vorgang mit Pull request merged und Review closed auf Closed setzen und die Arbeit ist für den Entwickler abgeschlossen.

Hier offenbart sich die Macht von Triggern in Entwicklungs-Workflows: Im Idealfall hat der Entwickler lediglich einen Vorgang ausgewählt und einen Zweig erstellt, aber sonst keinerlei händische Aktionen in JIRA ausführen müssen!

Nicht alle Wege führen nach Rom

Bei aller Euphorie und klaren Vorteilen gibt es jedoch auch einige Punkte beim Einsatz von Triggern, welche es gesondert zu beachten gilt.

  • Automatische Trigger und unbedachte globale Übergänge können zu ungewollten Ergebnissen führen. Beispielsweise wäre ein Commit Created-Trigger, um einen Vorgang immer in den Zustand In Progress zu forcieren die falsche Herangehensweise, da Commits auch häufig während einer In Review-Phase getätigt werden um Feedback einzuarbeiten.
  • Werden Workflow-Übergänge via Trigger ausgelöst, ignoriert JIRA alle Berechtigungen, Konditionen und Validatoren die für diesen Übergang gelten. Führt man die Aktion manuell aus gelten diese zwar, jedoch sollte man dies beim Workflow-Design im Hinterkopf beim behalten.

Trotz allem sind automatische Trigger sind ein mächtiges Werkzeug und ein willkommener Zusatz für das Design von JIRA-Workflows mit vielen Anwendungsmöglichkeiten. Ihr Einsatz sollte aber gut durchdacht werden.

Weitere Details und Informationen sind in der offiziellen Dokumentation zu JIRA-Triggern zu finden.