In 6 Schritten zu besserem Release-Management mit JIRA

Die entscheidende Frage – „Wann wird meine Änderung live sein?“ – muss jeder Entwickler beantworten können.
Aber die Entwicklungsabteilung ist nicht die einzige Gruppe, die darüber Bescheid wissen muss. Das gesamte Team muss wissen, wie es weitergeht und was die nächsten Schritte sind. Das Produktmanagement muss in der Lage zu sein, für die nächsten Ankündigungen von Features zu planen. Entwickler sind auf Feedback für ihre Arbeit aus. Zusammenfassend lässt sich sagen: Es ist immer eine Teamleistung.

In der Welt von DevOps wird die erledigte Arbeit oft mehrfach täglich in den master-Zweig integriert, aber es ist nicht immer sofort ersichtlich, wann Änderungen ausgeliefert werden. Entwickler haben die komplette Kontrolle darüber, wann Änderungen an den Kunden ausgeliefert werden. Damit ist es noch wichtiger, alle Vorgänge auch zu verfolgen. So können IT und Betrieb genau nachvollziehen, welche Änderungen mit welchem Release veröffentlicht wurden, und entsprechende Regressionen im Störfall identifizieren.

Mit JIRA Software oder JIRA Service Desk lassen sich die wichtigsten Schritte automatisieren. Hier sind die sechs Schritte für ein besseres Release-Management mit der JIRA-Produktfamilie:

1) Änderungen in Form von JIRA-Vorgängen festhalten

Nun, was beinhaltet eine Änderung eigentlich? Ist es ein einzelner Commit? Sind es mehrere Commits? Typischerweise bestehen lieferbare Arbeitspakete aus dem Letzteren — mehrere Arbeitsschritte gebündelt als neue Version.

Der wohl gängigste Weg, Änderungen zu verfolgen, besteht darin, Feature-Branches zu verwenden. Ist die Arbeit abgeschlossen, werden der Feature-Zweig mithilfe eines Pull Requests in master gemerget. Der Pull Request ist eine bessere Repräsentation für eine in sich geschlossene Arbeitseinheit. Oft gibt es jedoch trotzdem noch viele kleine, aber wichtige Änderungen die nachträglich — nachdem ein Pull Request gemerget wurde — durchgeführt werden müssen. So muss vielleicht die Farbe eines GUI-Elements angepasst oder der Text an einer anderen Stelle überarbeitet werden.

In diesem Fall gibt es vielleicht mehrere Pull Requests zu eigentlich derselben Änderungseinheit.

Anstatt nun mehrere einzelne, kleine Pull Requests zusammenzuflicken, sollte man diese in einer Änderungseinheit zusammenfassen. Genau hier ist es sinnvoll, JIRA Issues einzusetzen und damit Code, Prozesse und Menschen zusammenzubringen.

JIRA dient nicht nur der Nachverfolgbarkeit von Änderungen, es benachrichtigt auch Interessierte über den Fortschritt. Jeder im Unternehmen kann einem JIRA-Vorgang folgen und wird im Falle eines Kommentars oder einer Statusänderung benachrichtigt.

2) Den Workflow fürs Release Management in JIRA festlegen

Standardmäßig hat ein Workflow in JIRA keinerlei Informationen zum Stand der Veröffentlichung. Glücklicherweise ist die JIRA-Plattform flexibel und anpassbar. Wir können also einfach zusätzliche Status rund um den Zustand der Veröffentlichung hinzufügen.

Als Ausgangsvorlage dient der Standard-Workflow für Vorgänge in JIRA mit drei Zuständen:

Wir fügen dem bestehenden Workflow noch einige weitere Zustände hinzu. In unserem Fall möchten wir anstelle eines Übergangs von In Progress nach Done noch ein paar Zwischenschritte einfügen:

• Awaiting Release: Die Arbeit ist abgeschlossen und bereit zur Auslieferung.
• Released to Staging: Die Veröffentlichung in eine Testumgebung wurde ausgeführt.
• Released to Production: Endlich! Die Änderung wurde dem Kunden zur Verfügung gestellt.

Anbei ein Beispiel, wie der neue Arbeitsfluss mit den zusätzlichen Zuständen und Übergängen aussehen kann. Atlassian stellt auch eine umfangreiche Dokumentation rund um Workflows zur Verfügung.

3) Die agilen Boards konfigurieren

Sobald der neue Workflow abgespeichert wurde, kann dieser über die Projektkonfiguration aktiviert werden. Falls Ihre Entwickler Boards einsetzen, stellen Sie sicher, dass die neuen Zustände auch entsprechend zugeordnet werden.

Der einfachste Weg: Über die Board-Konfigurationsseite unter Spalten lassen sich die entsprechenden Zustände via Drag&Drop der Done-Spalte zuordnen:

Falls jetzt Entwickler Vorgänge von In Progress nach Done verschieben möchten, müssen sie den korrekten Zustand auswählen. In diesem Fall können sie mitteilen, ob eine Änderung bereit für die Veröffentlichung ist.

4) JIRA-Vorgänge Veröffentlichungen zuordnen

Nehmen wir an, ein Release wird aus einem Git-Repository heraus erzeugt. In diesem Fall können wir die Git-History verwenden, um alle Änderungen, die es in das Release schaffen, nachzuverfolgen. Trotzdem müssen wir die einzelnen Commits irgendwie Vorgängen in JIRA zuordnen.

Setzen wir den aktuellen Vorgangsschlüssel als Präfix vor die Commit-Nachricht, lässt sich der Commit einem Vorgang zuordnen:

$ git commit -am 'PROJ-255: change publish button colour to blue'


Dies erzeugt zwar etwas Overhead im Entwicklungsprozess ist aber eine gängige und gute Praktik, da dieses Vorgehen Nachverfolgbarkeit und Historisierung sicherstellt. Alternativ kann man den Vorgangszweig nach dem Vorgangsnamen in JIRA benennen. So werden alle Commits innerhalb des Zweiges dem Vorgang zugeordnet.

Erzeugt man einen solchen Zweig aus JIRA Software heraus, wird dieser automatisch nach dem Vorgangsschlüssel benannt.

5) Alle relevanten Änderungen für die nächste Veröffentlichung finden

Der wichtigste Teil: Nachverfolgen, welche der Änderungen in eine Veröffentlichung gepackt werden sollen. Nachdem ein Release zusammengestellt wurde, sollten Sie den Commit mit der Versionsnummer versehen.

Ein Beispiel für ein Kommando, welches man dem Buildscript hinzufügen kann:

$ git tag -s -a 6.0.0-OD-2016.12.1-1106 && git push $remote 6.0.0-OD-2016.12.1-1106


Wir nutzen Git, um alle Commits zwischen dem aktuellen und vorigen Release-Tag herauszufinden. Aus der Git-History können wir mit folgendem Kommando die passenden Vorgangsschlüssel aus den Commits extrahieren:

$ git log 6.0.0-OD-2016.11.1-1091..6.0.0-OD-2016.12.1-1106 --pretty=oneline | perl -ne '{ /(\w+)-(\d+)/ && print "$1-$2\n" }' | sort | uniq
CONF-38645
CONF-40446
CONF-40973
CONF-41003
CONF-41014
CONF-41035


Und hier ist sie: Die Liste der JIRA-Vorgänge für die nächste Veröffentlichung!

Mit ein wenig mehr Arbeit kann aus dieser Liste eine JQL-Anfrage für den JIRA-Server gebastelt werden:

issue in ('CONF-41003', 'CONF-40973', 'CONF-38645', 'CONF-40446', 'CONF-41014', 'CONF-41035') and status = 'AWAITING RELEASE'


Manche dieser Commits beschreiben unter Umständen erst teilfertige Arbeit, deshalb möchten wir alle Vorgänge filtern, die nicht im Awaiting Release-Zustand sind.

Nachdem wir die Liste aller Vorgänge für die neuste Version erhalten haben, müssen wir diese aktualisieren. Dies kann entweder manuell mit dem Bulk Update-Feature von JIRA direkt aus der Suchanfrage oben geschehen, oder man führt im Rahmen des Release-Builds ein Script aus. Ein Beispiel hierfür ist das Python jira-Paket, mit welchem via Python mit der JIRA Rest API kommuniziert werden kann.

6) Veröffentlichen und Beteiligte informieren

Jetzt sind wir in der Lage, eine neue Version zu veröffentlichen – was nun? Es ist an der Zeit, auszuliefern. JIRA-Vorgang updaten, Beteiligte informieren und ab die Post. Zur Veröffentlichung benötigt man die entsprechende Version und Umgebung, in welche veröffentlicht wird. Im Anschluss lassen sich alle Vorgänge in den passenden Zustand überführen: Released to Staging oder Released to Production.

Sobald ein Deployment erfolgreich durchgeführt wurde, können Sie nach allen Vorgängen innerhalb des Releases mit dieser JQL-Anfrage suchen (dies lässt sich entweder als Teil des Buildvorgangs oder manuell ausführen):


fixVersion = '6.0.0-OD-2016.12.1-1106'


Mit dem Bulk Update-Feature oder Script-Update über die REST API können die zutreffenden Vorgänge nun abhängig von der Umgebung, in welche veröffentlicht wurde, nach Released to Staging oder Released to Production überführt werden.

Wenn die Vorgänge aktualisiert werden, werden alle Entwickler und Beteiligte, die dem Ticket folgen, darüber benachrichtigt, dass die Änderung in die Testumgebung oder zum Kunden ausgeliefert wurde.