JIRA anzapfen

Aus der Feder eines Pragmatischen

Ein geschätzter ehemaliger Kollege der Softwareforen entwarf vor etwa zwei Jahren einen interessanten Blogartikel. Konkret ging es dabei um ein Problem mit JIRA, dem eine kleine Anekdote vorausging:

Vor einiger Zeit haben wir zur Qualitätssicherung unsere Tickets kontrolliert. Wir haben dazu Regeln definiert, die diese Tickets einhalten sollen. Natürlich mussten diese Regeln auch geprüft werden, daher hatte der Kollege einmal die unliebsame Aufgabe, diese Tickets zu kontrollieren. Hier die Geschichte des pragmatischen Kollegen:

Ich bin faul – zumindest bei Sachen, die ich nicht gerne mache. Darunter fallen bei mir zum Beispiel „Verwaltungsaufgaben“. Wenn ich das schon höre, denke ich an ein kleines, dunkles Büro mit einem riesigen Berg todlangweiliger Arbeiten, die man ohne groß nachzudenken, erledigen kann. Das Problem an der Sache ist – ich denke dann wirklich nicht mehr nach. Dies hat meistens zur Folge, dass ein Teil dieser Aufgaben nur unvollständig erledigt oder fehlerhaft ist. Und genau so eine Aufgabe lag auf meinem Tisch in Form einer Klarsichtfolie voller kleiner, gelber Zettel.
Bei uns wandern diese kleinen Zettel von links nach rechts über ein Kanban-Board, um dann letztlich in der Klarsichthülle zu landen. Dem Projektverantwortlichen fällt nun die glorreiche Aufgabe zu, eben diese Zettel bzw. die JIRA-Tickets, die damit verknüpft sind, auf Vollständigkeit zu prüfen: Wurde die Zeit richtig gebucht? Gibt es eine Beschreibung? Wurde eine QA durchgeführt usw. Nach dem dritten Zettel gab ich auf.

Solche immer gleichen Arbeitsschritte kann man doch automatisieren!? Stellt JIRA eigentlich Schnittstellen bereit? Lassen sich die Prüfungen auch in Quellcode gießen? Ja, ja und nochmals ja!

Eine Webanwendung sollte her, ich bin schließlich nicht der Einzige, der diese Prüfungen machen muss. Außerdem sollte die Entwicklung schnell gehen, großartige Styleanpassungen waren nicht zu erwarten, meine Wahl fiel deshalb auf Vaadin. Damit lassen sich recht schnell ansehnliche Oberflächen zusammenstellen.

Vorgestellt hab ich mir etwas ähnliches wie dies:

Mockup

Also bauten wir uns schnell die Anwendung zusammen.

Maven Konfiguration

Ich gehe hier nicht weiter darauf ein, wie man eine Java-Webanwendung mit Maven aufsetzt. Man kann direkt den Vaadin-Archetype verwenden oder den Standard maven-archetype-webapp und alle nötigen Abhängigkeiten manuell hinzufügen. Das ist jedem selbst überlassen.

Atlassian stellt erfreulicherweise direkt eine API zur Verfügung, mit der man mit JIRA kommunizieren kann. Dafür fügen wir zuerst das Maven-Repository von Atlassian in unserer pom hinzu:

Und nun die API selbst:

Das sollte es für Maven auch schon gewesen sein.

Implementierung

Erfreulicherweise ist die Arbeit mit der API kinderleicht. Zuerst muss man natürlich eine Verbindung mit JIRA aufbauen. Die Verbindung wird mit einem Benutzer aufgebaut, dessen Berechtigungen für alle zu kontrollierenden Tickets reichen muss.

Mit dem IssueRestClient kann man nun auf die Tickets zugreifen und die Informationen daraus lesen, bearbeiten oder löschen. Um dann von einem Ticket die Zusammenfassung, also den Namen, zu erhalten, kann folgender Code verwendet werden:

Ab hier sind natürlich alle Spielereien denkbar. Für uns war wichtig, dass bestimmte Zeiten am Ticket eingehalten wurden, dass die Arbeitsbeschreibungen vorhanden waren und der Status der Tickets auch nach der Bearbeitung des Quellcodes gepflegt wird.

Fazit

JIRA bringt alles mit, was für einen einfachen aber sicheren Zugriff von außen auf das System ermöglicht. Natürlich ist ein Zugriff auch über das Schreiben von Plugins möglich. Welche Architektur besser passt, hängt vom Projekt und den Anforderungen ab. Für diesen Anwendungszweck ist beides denkbar.

Natürlich war der Kollege so fair und hat diese Entwicklung den anderen Kollegen überlassen, damit sie es nicht weiterhin so schwer haben 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.