JIRA mit Plugins erweitern Überblick und Möglichkeiten, jira plugins addons erweitern vom hacker zum entwickler, dev tools Image

JIRA mit Plugins erweitern – Überblick und Möglichkeiten

3 Kommentare

JIRA ist ein Projekt-, Prozess- und Produkt-Management-Tool von Atlassian, das in der agilen Softwareentwicklung weit verbreitet ist, längst aber auch über die IT-Abteilung hinaus eingesetzt wird. Über 70% der Fortune 100 Unternehmen setzten JIRA ein. Sind die umfassenden Konfigurationsmöglichkeiten ausgeschöpft, kann JIRA dank seiner erweiterbaren Architektur, basierend auf dem Atlassian-Plugin-Framework, weiter an die eigenen Bedürfnisse angepasst werden. Die Bandbreite von Plugins reicht dabei von Erweiterungen für Workflows über Anpassungen der Benutzeroberfläche bis zur Integration von eigenen Webanwendungen und Services. Der Artikel beschreibt die Architektur von JIRA, gibt einen Überblick der Möglichkeiten für Erweiterungen und soll den Einstieg in das Atlassian-Plugin-Framework erleichtern.

Einleitung

JIRA ist ein beliebtes Tool in der Softwareentwicklung. Längst hat es seine ursprüngliche Funktion Fehler/Bugs und Aufgaben zu verwalten, weit hinter sich gelassen. So unterstützt es agiles Projektmanagement nach Scrum und Kanban, aber auch für allgemeine Aufgabenverwaltung und die Implementierung von anderen Geschäftsprozessen kommt es zum Einsatz. Nicht zuletzt ist es auch für Produkt-Management geeignet, insbesondere in Verbindung mit dem Kollaborationstool Confluence.

Über 35.000 Kunden setzen weltweit JIRA ein, darunter 70% der Fortune 100 Unternehmen.

Ein entscheidender Erfolgsfaktor von JIRA (und Atlassian Produkten im Allgemeinen) sind die unzähligen Möglichkeiten die Software anzupassen und zu erweitern. Neben kleineren „Hacks“ zur Anpassung der Benutzeroberfläche (z.B. Laden von Java-Script über Announcement Banner oder Custom Fields, Modifizieren der original HTML-Templates) und Scripten für Datenimporte, -exporte und Workflow-Verhalten gibt es ein robustes Fundament mit offener und erweiterbarer Architektur.

Zur Erweiterung bzw. Anpassung von Workflows existieren bereits zahlreiche Add-Ons, welche jedoch teilweise relativ hochpreisig im Vergleich zum Preis der JIRA Basisinstallation sind und bei den derzeit frei verfügbaren Add-Ons sollte deren Lizenz genau geprüft werden, da es vorkommt, dass ein Add-On zunächst frei verfügbar ist, plötzlich aber bezahlt werden muss. So z.B. geschehen beim beliebten Add-On “Misc Workflow Extensions” zur Anpassung von Workflows.

Atlassian verwendet den Begriff “Add-On” und “Plugin” als Synonyme, im Folgenden werden diese auch als Erweiterungen bezeichnet.

Plugin Generationen

Ein Plugin ist ein Paket bestehend aus Quelltext, Ressourcen und Konfigurationsdateien. Folgende Plugin-Generationen können im Atlassian Umfeld unterschieden werden:

  • “Version 1” Plugins. Die erste Generation von Plugins lief direkt im JIRA-Kernsystem und verwendeten den selben Classloader. Jedes Atlassian Produkt hatte sehr unterschiedliche Erweiterungsmöglichkeiten.
  • “Version 2” Plugins (Seit JIRA 4). Die zweite Generation von Plugins läuft in einem OSGi Container. Dadurch hat jedes Plugin seinen eigenen Classloader, Abhängigkeiten können über OSGi verwaltet werden. Alle Atlassian Produkte verwenden das selbe Fundament.
  • “Speakeasy” Plugins (Ab JIRA 4.3). Dieser Plugin Typ ist rein auf JavaScript/HTML basiert. Ziel ist/war es, den Entwicklungsprozess für simple Erweiterungen zu vereinfachen. Seid 2013 wird das Projekt leider nicht mehr weiter entwickelt. Auch wird vom Einsatz in öffentlich zugänglichen JIRA Instancen nach wie vor abgeraten.
  • “Connect“ Plugins (Seid 03/2014, für JIRA OnDemand). Erweiterungen für die JIRA Cloud Version können mit dem Connect Framework entwickelt werden. Diese können dann aber ausschließlich für diese betrieben werden. Einfach gesagt sind Connect Plugins Web Anwendungen, die mit JIRA über REST-Schnittstellen kommunizieren. Dadurch können Sie völlig unabhängig von JIRA entwickelt und betrieben werden, sind aber auch abhängig von den zur Verfügung stehenden REST-Schnittstellen und können naturgemäß nicht auf die zahlreichen JAVA-APIs zugreifen wie ein Version 2 Plugin.

Dieser Artikel beschäftigt sich mit den Version 2 Plugins. Sie sind derzeit die erste Wahl wenn ein selbst-gehosteter JIRA Server im Einsatz ist.

Version 2 Erweiterungen werden wie erwähnt separat vom Kernsystem entwickelt, installiert und betrieben. Sie können (dank OSGi) während des Betriebs installiert und deinstalliert werden.

Das Atlassian Plugin Framework (APF) ermöglicht es, sich nahtlos in die JIRA-Architektur einzufügen und nahezu jede Komponente auszutauschen bzw. zu erweitern. JIRA selbst ist de Facto nur eine Menge von Plugins für das Atlassian-Framework.

Atlassian pflegt eine Open Source Kultur und so ist es von großem Vorteil dass man sowohl in die von Atlassian verwendeten Bibliotheken Einblick hat, als auch vollen Zugriff auf den Source Code von JIRA bekommt. Nach dem Kauf einer Lizenz kann dieser unter my.atlassian.com heruntergeladen werden.

Im Folgenden soll kurz beschrieben werden, wie JIRA funktioniert, welche Möglichkeiten zur Anpassung es gibt und an welcher Stelle Erweiterungen Sinn machen könnten.

 JIRA-Architecture-Plugin-Framework

Bild JIRA Architektur, Quelle: Atlassian, eigene Anpassung.

JIRA Issues

Das Herz von JIRA sind die sogenannten Issues, die einen definierten Workflow durchlaufen. Zu deutsch sind das Tickets (bzw. Vorgänge) die einem Arbeitsablauf folgen. Welche Felder ein Ticket hat, kann frei definiert werden. Die einzelnen Felder haben verschiedene Typen, z.B. erlauben sie Freitexteingaben, diverse Zahlenformate, Datumseingaben über einen Kalender oder aber eine vordefinierte Auswahlliste deren Werte im Administrationsbereich von JIRA konfiguriert werden. Eigene Formate bzw. Typen können als Erweiterung hinzugefügt werden. Im Abschnitt “Eigene Typen für benutzerdefinierte Felder” wird darauf näher eingegangen.

Hacking vs. Erweitern

JIRA erlaubt in vielen Fällen die Eingabe von HTML/JavaScript im administrativen Bereich. So kann z.B. ein global sichtbares Banner die Benutzer mit wichtigen Informationen versorgen, etwa für bevorstehende Updates. Auch die Beschreibung von Custom Fields kann HTML/Javascript enthalten.

In beiden Fällen kann es so gelingen JavaScript in die Applikation zu schleusen.

Seid JIRA 6.2 wurden die Möglichkeiten JavaScript Code derartig in die Applikation zu bekommen eingeschränkt.

Wenngleich es diese Möglichkeiten gibt, ist dies, insbesondere bei größeren Installationen, nicht empfehlenswert:

  • Scripts müssen/werden häufig direkt in der produktiven JIRA Instanz entwickelt bzw. getestet, was fehleranfällig und schlecht wartbar ist.
  • Scripts werden in Textfeldern hinterlegt und Änderungen müssen manuell gepflegt werden.
  • Fehlende Versionierung: Es ist nicht klar mit welchen Versionen von JIRA ein Script kompatibel ist, noch welche Version des Scripts “installiert” ist.
  • Hacks der Benutzeroberfläche können zu Schwierigkeiten bei Updates von JIRA führen.
  • Fehlende Übersicht für Administratoren, wo Scripts auf welche Art und Weise eingeschleust wurden.
  • Hoher manueller Testaufwand durch fehlende Testautomatisierung.
  • Ab JIRA 6.2 sind einige dieser Möglichkeiten standardmäßig deaktiviert.

Für administrative Tätigkeiten, einmalige Exports oder für’s Prototyping sei an dieser Stelle das Add-On Script Runner erwähnt. Durch die Möglichkeit, eigenen Groovy-Code auszuführen ist es sehr mächtig und kann für produktive Hacks (Scripted Fields, Scripted JQL Functions) eingesetzt werden.

Erweiterungen können im Gegensatz dazu sauber installiert und deinstalliert werden. Sie folgen sowohl in der Entwicklung als auch in Produktion einem Lebenszyklus, können über ein Versions-Kontrollsystem vernünftig verwaltet und über ein maven-basiertes Build Tool (dazu im nächsten Abschnitt mehr) paketiert und veröffentlicht werden. Dies ermöglicht ein strukturiertes – oftmals auch automatisiertes Testen.

Update: An dieser Stelle der Hinweis zu unserer 4-teiligen Blog Serie: Agiles Testen von JIRA Plugins (Teil 1), Wired Tests (Teil 2), Systemtests (Teil 3), CI Server Integration und Test Coverage (Teil 4).

Darüber hinaus können Plugins einzeln an neue Versionen von JIRA explizit angepasst werden und so updatesicher werden. 

Eigene Komponenten entwickeln

Einen sehr guten Einstieg in die Plugin Entwicklung bietet die offizielle englische Entwickler Dokumentation. Das Atlassian Framework besteht im Wesentlichen aus folgenden Komponenten:

  • Einem Maven-basierten Build Tool: AMPS.
  • Java-APIs und –Bibliotheken, um auf Atlassian Funktionen und Produkt-spezifische Funktionen zuzugreifen. Für einen kompletten Überblick siehe Link.
  • Einem JavaScript Framework (AJS)
  • Einem HTML/CSS Framework zur Entwicklung von Benutzeroberflächen: AUI.
  • Diversen Atlassian-Add-Ons, insbesondere
    • Der Universal Plugin Manager (UPM): Ein Plugin, das es ermöglicht Plugins zu verwalten. (klingt komisch, ist aber so)
    • FastDev: installiert das Plugin, welches gerade entwickelt wird, bei Änderungen am Quellcode neu, ohne den gesamten Container (also die JIRA-Anwendung) neu laden zu müssen.

AMPS, das Atlassian Maven PlugIn System, bringt eine Reihe von Kommandozeilen-Befehlen mit, welche die Entwicklung eigener Komponenten unterstützt. Die Atlassian maven-Kommandos bieten Support für den gesamten Plugin-Entwicklungs-Lebenszyklus inklusive Starthilfe für neue Module durch Generierung der benötigten Quellcode- und Konfigurationsdateien.

Ein einfacher Lebenszyklus bei der Entwicklung eines JIRA Plugins könnte wie folgt aussehen:

> atlas-create-jira-plugin

Erstellt die Grundstruktur für das Plugin: Verzeichnisse und Dateien werden angelegt. Etwas Beispielcode wird erzeugt, um den Einstieg zu erleichtern.

> atlas-create-jira-plugin-module

Erstellt ein JIRA Modul. Aktualisiert die Plugin Konfiguration und erstellt je nach Modul entsprechende Dateien und Verzeichnisse.

> atlas-run

Startet eine Entwickler-JIRA-Instanz und lädt das Plugin, das sich im aktuellen Verzeichnis befindet.

> atlas-package

Paketiert das Plugin als auslieferbares Artefakt (jar)

Atlassian-plugin.xml / Add-On Descriptor

Dreh- und Angelpunkt eines Atlassian-Plugins ist der sog. Descriptor: Die XML-Konfigurationsdatei „atlassian-plugin.xml”. In dieser Datei wird das Plugin formal beschrieben: Basisinformationen wie z.B. der Name und ein eindeutiger Schlüssel (plugin key) werden hinterlegt. Darüber hinaus werden hier Ressourcen, Abhängigkeiten und Komponenten definiert.

Add-On Module zur Erweiterung von JIRA

Über 30 Modultypen stehen für JIRA zur Auswahl. Diese kann man in folgende Kategorien unterteilen:

  • Erweiterung der Benutzeroberfläche (Web Item, Web Panel, Web Panel Renderer, Web Section, Component Tab Panel, Issue Tab Panel, Project Tab Panel, Version Tab Panel, Template Context Item, User Format Plugin, User Profile Plugin)
  • Web Ressourcen (Web Resource, Web Resource Transformer, Downloadable Plugin Resource)
  • Workflow-Erweiterungen (Workflow Condition, Workflow Post Function, Workflow Validator)
  • Eigene Serviceklassen (Component, Component Import, Module Type)
  • Erweiterungen für neue Custom Fields (Benutzerdefinierte Felder) (Custom Field, Custom Field Searcher)
  • Gadgets (Gadget Plugin Module)
  • Web-Schnitstellen (REST Plugin Module, RPC Endpoint Plugin)
  • Reports und Suchergebnisse (Report, Search Request View)
  • Eigene Web-Apps, Seiten und Servlets (Webwork Plugin, Servlet, Servlet Filter, Servlet Context Listener, Servlet Context Parameter, URL Routing Plugin)
  • JQL Erweiterungen (JQL Function)
  • Tastaturkürzel (Keyboard Shortcut)
  • Support bei der Lizenzierung

Darüber hinaus gibt es noch weitere Möglichkeiten die Software zu erweitern. Die obige Auflistung sollte aber einen guten Überblick bieten. Für die Plugin Entwicklung ist neben der offiziellen Entwickler-Dokumentation der JIRA Sourcecode eine gute Quelle für Dokumentation und gibt Einblick in die Funktionsweise. Im Modul „jira-reference-plugin“ sind die meisten Module beispielhaft implementiert.

JIRA Workflows und Workflow-Funktionen

Jedes JIRA-Ticket ist einem bestimmten Workflow zugewiesen. Ein Workflow ist charakterisiert durch verschiedene Zustände (Statuses) und Übergänge zwischen diesen Zuständen (sog. Transitions).

Der Wechsel zwischen verschiedenen Zuständen in einem Workflow ist geknüpft an

  • Vorbedingungen (conditions)
  • Validatoren (validators)
  • Folgefunktionen (post functions)
  • Trigger

Workflows sind ein zentraler Bestandteil von JIRA und sollten genau an die Unternehmensprozesse angepasst werden. Eigene Workflow-Funktionen führen zu größtmöglicher Flexibilität und Automatisierung der Arbeitsabläufe.

Folie1

Bild JIRA Workflow Funktionen.

Eine Vorbedingung (“condition”) wird ausgewertet, bevor überhaupt die Möglichkeit gegeben wird einen Übergang, z.B. von Status „offen“ in Status „abgeschlossen“, auszuführen. Sprich, ein entsprechender Button, um einen Übergang durchzuführen, wird dem Benutzer nur angezeigt, wenn alle Vorbedingungen erfüllt sind. Ein typischer Einsatz einer Vorbedingung ist, zu überprüfen, ob der Benutzer eine bestimmte Berechtigung hat.

Sind alle Vorbedingungen erfüllt, kann mit Validatoren (“validators” / auch Bestätigungen genannt) überprüft werden, ob Eingaben korrekt sind. Gibt ein Validator einen Fehler zurück, so wird dieser dem Benutzer angezeigt und der Übergang wird nicht durchgeführt.

Sind Vorbedingungen und Validatoren erfolgreich passiert, kommen die Folgefunktionen (“Post-Functions”) zum Einsatz. Es gibt eine Reihe von Standard-Folgefunktionen die bei jeder Transition ausgeführt werden, z.B. wird der Status des Tickets aktualisiert und in der Datenbank persistiert oder ein Kommentar des Benutzers wird dem Ticket hinzugefügt. Darüber hinaus bringt JIRA eine Reihe optionaler Folgefunktionen mit, so z.B. um das Issue einem Benutzer zuzuweisen, den Wert eines Feldes zu setzen oder aber auch einen „Webhook“ auszulösen.

Ein einfacher Anwendungsfall einer Post-Funktion ist z.B., ein Ticket-Feld auf einen bestimmten Wert zu setzen oder das Ticket einer bestimmten Person zuzuweisen.

Um andere Anwendungen über Workflow-Ereignisse zu benachrichtigen, können Webhooks und Trigger eingesetzt werden.

Ein Webhook ist ein HTTP-Post Aufruf einer bestimmten URL, ausgelöst durch ein Ereignis (z.B. neues Ticket erstellt).Übertragen wird ein JSON Objekt des Tickets, für das das Event ausgelöst wurde. Webhooks können durch allgemeine Events ausgelöst werden, aber auch – wie bereits erwähnt – durch eine Post-Funktion. Eine andere Webanwendung kann so bei bestimmten Events benachrichtigt werden.

Eine neue Art Workflow Funktion seit JIRA 6.3.3 sind Trigger. Im Gegensatz zu Webhooks erlauben sie es, externe Events von anderen Anwendungen zur Steuerung von Workflows in JIRA zu verwenden. Derzeit werden Trigger für Stash, FishEye/Crucible, Bitbucket und GitHub angeboten. Ein häufiger Anwendungsfall ist, bei einem Event den Status eines Tickets zu verändern. So kann z.B. das Erstellen eines Entwicklungs-Branches in Bitbucket/Github ein gleichnamiges Ticket in den Status “In Bearbeitung” überführen. Über die Entwicklung von eigenen Triggern liegen derzeit keine Informationen vor.

Anpassung und Erweiterung der Benutzeroberfläche

Die Benutzeroberfläche von JIRA ist stark konfigurierbar und kann durch sog. „web fragments“ zusätzlich erweitert werden. Die Add-On Modul-Typen„web items“, „web sections“ und „web panels“ bieten Möglichkeiten zur sauberen Erweiterung. Dadurch können Menüs mit eigenen Menüpunkten ergänzt werden, in Detailansichten können neuen Buttons, Reiter, Felder und Sektionen eingefügt werden.

 JIRA web items. Möglichkeiten der Anpassung der Benutzeroberfläche.

JIRA Issue-Detail Ansicht, in rot eine Auswahl an Sektionen die über web items/sections hinzugefügt werden können.

Web Ressourcen

Statische Dateien wie z.B. JavaScript, CSS-Stylesheets und Bilder werden in der Datei atlassian-plugin.xml definiert und über einen Schlüssel können diese dann im Java/JavaScript Code oder in einem Template verwendet werden. Darüber hinaus besteht die Möglichkeit, die Dateien vor der Auslieferung noch zu transformieren. Ein Beispiel dafür ist der i18n Transformer: bestimmte Begriffe im JavaScript-Quelltext werden vor der Auslieferung übersetzt bzw. internationalisiert.

Einleitend wurde erwähnt, wie man über “Hacks” eigenen JavaScript in JIRA integrieren kann. Die bessere Alternative sind hier Web Resourcen. Über den “web resource context” kann angegeben werden in welchen Bereichen von JIRA eine Ressource geladen werden soll. So kann z.B. über den context “jira.view.issue” in der Ticket-Detailansicht zusätzlicher JavaScript geladen werden. Atlassian bietet eine Liste aller möglichen Kontexte. Wenngleich auch hier keine Updatesicherheit gegeben ist so bietet dieser Ansatz dennoch die Vorteile die man mit Plugins im Vergleich zu den eingangs genannten hacks hat.

Eigene Typen für benutzerdefinierte Felder

Wie bereits eingangs erwähnt, gibt es für Tickets vordefinierte Felder sowie benutzerdefinierte Felder. Ein benutzerdefiniertes Feld hat immer einen bestimmten Typ, z.B. für die Eingabe von Zahlen, freien Text, Datumseingaben oder einer Auswahlliste mit Benutzern. Reichen die vordefinierten Typen nicht aus, können eigene entwickelt werden (sog. „custom field types“). Ein einfaches Beispiel, das nicht von JIRA mitgeliefert wird, ist der Typ „Ganze Zahl“ oder “Prozentzahl” (lediglich Fließkommazahlen werden out-of-the-box angeboten). Ein weiteres Einsatzgebiet ist die Anzeige von Listen mit dynamischen Inhalt. Diese Inhalte können z.B. von internen Services bereitgestellt werden. So kann z.B. eine Liste der Abteilungen abgefragt werden, um ein Ticket einer Abteilung zuzuweisen. Auch komplexe kaskadierende Listen sind ein guter Anwendungsfall. Für den Einsatz von JIRA in einem Automobilunternehmen soll z.B. ein Vorgang erstellt werden, welcher unter anderem auch die Auswahl eines Fahrzeug-Modells und darauf basierend einer Unterversion ermöglicht. Die Daten dafür könnten über eine Schnittstelle aus dem internen ERP System bezogen werden.

Eigene Typen für benutzerdefinierte Felder bieten also umfangreiche Möglichkeiten Formulare zu erweitern.

 

Über Konfiguration abbildbarErweiterung (custom field types) notwendig
Einfache Formate wie z.B. Datum oder Nummern. Einfache Auswahllisten.Spezielle Formate, z.B. Seriennummern, Artikelnummern.
Auswahllisten von externen Datenbank/Webservices in Anhängigkeit von anderen Feldern.

Tabelle: Vergleich der Möglichkeiten von Konfiguration und eigenen Typen für custom fields.

Berichte

Berichte (Reports) sind Ad-Hoc Statistiken. Sie sind meist projektbezogen und erlauben es, auf Grundlage der Ticketseines Projekts Daten in aggregierter oder angereicherter Form darzustellen. JIRA bringt einige (wenige) Berichte in seiner Standardausführung mit. Hierzu zählt der Bericht über das „Durchschnittliche Alter von Tickets“, „Erstellte vs. Gelöste Tickets“ und einige mehr.

Die mitgelieferten Berichte stoßen schnell an ihre Grenzen. Hier macht eine Erweiterung durchaus Sinn. Das Add-On Modul „Report“ wird in der Datei atlassian-plugin.xml spezifiziert und enthält typischerweise:

  • Name, eindeutigen Schlüssel und Beschreibung (wie alle Add-Ons)
  • Referenz auf die Java-Klasse die den Report erzeugt. (Diese implementiert das Interface Report (link!) bzw. wird von der Klasse AbstractReport (link!) abgeleitet)
  • Parameter die der Benutzer eingeben kann
  • Template für die Darstellung im HTML Format (meist Velocity)
  • (optional) Template für die Darstellung als Excel. Dies ist im Wesentlichen eine einfache Tabelle. Umfassende Excel Reports sind nur mit Mehraufwand möglich, aber durchaus machbar.

JQL, Suchergebnisse und Filter

Eine wichtige Komponente von JIRA ist die Ticket-Suche. Eine einfache Maske erlaubt es einfache Suchergebnisse per Auswahl zu definieren z.B. alle Tickets mit einem bestimmten Status in einem bestimmten Projekt aufzulisten.

Mithilfe der JIRA Query Language (JQL, in Anlehnung an die Datenbank-Abfragesprache SQL) können auch komplexe Abfragen definiert werden.

Der Ausdruck nach dem gesucht wird (Operand) kann ein definierter Wert (z.B. Projekt “Mars 2030”) sein, oder aber auch eine Funktion. JQL unterstützt eine Reihe von Funktionen, z.B. gibt currentUser() den aktuell eingeloggten Benutzer zurück, oder watchedIssues() eine Liste der beobachteten Vorgänge des eingeloggten Benutzers.

Ein Beispiel für eine JQL Abfrage: Gesucht werden Vorgänge im Projekt Mars 2030 die “mario” zugewiesen sind und vom aktuell eingeloggten benutzer vom Status “done” in den status “closed” verschoben wurden:

project=“Mars 2030″ and assignee in („mario“) and status changed BY currentUser() FROM Done to Closed

Eigene JQL-Funktionen können mit dem Modultyp “JQL Function” realisiert werden. So könnte z.B. eine Funktion issuesWithSubtasks(3) alle Tickets zurückliefern, für die 3 Unter-Tickets erstellt worden sind.

Suchabfragen können als “Filter” gespeichert werden. Dadurch kann man einerseits selbst jederzeit die Abfrage schnell erneut ausführen, darüber hinaus kann man Filter aber auch mit anderen Personen teilen und die Filter per E-Mail abonnieren um z.B. täglich eine Liste der abgeschlossenen Tickets zu erhalten.

Zur Darstellung der Suchergebnisse gibt es out-of-the-box diverse Möglichkeiten, z.B. eine HTML-Listenansicht, PDF, Word, Excel, eine Druckansicht oder auch RSS. Die HTML Ansicht ist stark konfigurierbar wohingegen die anderen Optionen schon deutlich eingeschränkterin ihren Konfigurationsmöglichkeiten ausfallen.

Eigene Formate sind als Erweiterung mit einem Plugin vom Typ “search request view” zu realisieren. So kann z.B. eine angepasste PDF-Ansicht entwickelt werden, oder ein spezielles XML Format als Ergebnis zurückgeliefert werden.

Gadgets

Dashboards spielen in JIRA eine zentrale Rolle. Es sind anpassbare Übersichtsseiten, die dem Benutzer einen schnellen Überblick über Projekte, Tickets etc. geben sollen. Neben dem vom Administrator vordefinierten Systemdashboard ist die Startseite eines Benutzers meist sein persönliches bzw. favorisiertes Dashboard. Ein Dashboard besteht aus einem oder mehreren Gadgets; diese zeigen z.B. Tickets, die dem Benutzer zugewiesen sind, oder Diagramme für statistische Informationen eines Projekts.

Gadgets können frei kombiniert werden und erlauben es so stark personalisierte Ansichten für verschiedene Zwecke zu definieren.

Typische JIRA Gadgets sind:

  • der Aktivitätsstrom: Anzeige von Aktivitäten in einem einzelnen oder allen Projekten
  • Mir zugewiesene, von mir erstellte und beobachtete Tickets
  • Diagramme zum durchschnittlichen Alter von Tickets, Anzahl der erstellten vs. erledigten Tickets
  • Filterergebnisse (gespeicherte Suchen von Tickets)
  • Aktuelle Informationen und nützliche Links, gepflegt von der JIRA Administration.

Die Entwicklung eigener Gadgets ermöglicht es, Informationen jeglicher Art auf Dashboards zu bringen. Dies können JIRA-interne Daten, externe oder auch eine Kombination von internen und externen Daten sein.

Atlassian-Gadgets basieren auf Google+ Gadgets bzw. Open Social Gadgets und werden in JavaScript/HTML entwickelt. Die Daten werden meist über einen REST-Webservice geladen.

Ein typisches Gadget-Plugin umfasst:

  • Eine XML-Konfigurationsdatei („gadget.xml“)
  • Das Atlassian JavaScript Framework (AJS)
  • Eingebundene Web Ressourcen: JavaScript, HTML-Templates und CSS (siehe auch Abschnitt Web Ressourcen)
  • REST-Services, die Daten liefern.

Wenngleich es möglich ist, Gadgets „stand-alone“ zu entwickeln, verliert man dadurch Unterstützung vom AJS-Framework und weitere Komfortfunktionen. Es empfiehlt sich also Gadgets in ein “Atlassian Plugin” zu packen.

Eigene REST-Schnittstellen

Ein wichtiges Modul einer Web-Anwendung sind die Web-Schnittstellen. JIRA setzt hier auf REST-basierte Schnittstellen. Es stellt eine Vielzahl an Funktionen bereit, um Daten aus JIRA zu lesen, JIRA zu konfigurieren oder Daten zu schreiben. Wenn dies nicht ausreicht, kann man aber auch hier Hand anlegen und zusätzliche REST-Module entwickeln. Dieses wird wie alle anderen Module auch in der atlassian-plugin.xml definiert und basiert auf JAX-RS bzw. Jersey und für die Konvertierung von Java-Objekten zu XML/JSON wird JAXB eingesetzt. 

Eigene WebApps in JIRA

Will man völlig neue Funktionalität in JIRA realisieren oder eine vorhandene eigene WebApp integrieren, kann man auf die Plugin Module “Web Work Actions” und “Active Objects” zurückgreifen. Darüber hinaus können natürlich Servlets oder eigene Frameworks eingesetzt werden.

Das Web Work Actions Plugin Modul bietet eine einfache Möglichkeit komplette eigene Seiten bzw. WebApps in JIRA zu entwickeln. Dabei wird eine “action” Klasse definiert die auf einen bestimmten URL Pfad antwortet. Eine Methode “füllt” dann ein Velocity-Template, rendert es und der Browser kann es somit anzeigen.

Die Interaktion mit der Datenbank von JIRA wird über “Active Objects” (AO) realisiert. Dieses ORM-Framework folgt dem “active record pattern” mit dem Ziel eine einfach Interaktion mit der Datenbank zu ermöglichen. Die Objekte bzw. Tabellen werden als Klassen definiert, die von der Klasse Entity abgeleitet werden (oder RawEntity implementieren). Die Erstellung der Tabelle, sowie mögliche Änderungen am Schema übernimmt das Framework. Das Framework nimmt dem Entwickler in der Tat einiges an Arbeit ab und abstrahiert die Datenbank erfolgreich.

Fazit

Zusammenfassend kann man sagen, dass die Erweiterungsmöglichkeiten von JIRA sehr umfassend sind. Die Entwicklung von Plugins mit dem Atlassian-Framework ist entwicklerfreundlich und relativ gut dokumentiert.Ein großer Vorteil bei der Entwicklung ist die Verfügbarkeit des Quelltextes von JIRA und die Referenz-Implementierung der einzelnen Plugin Module.

Die Plugins sind dank OSGi sauber voneinander abgegrenzt und können dennoch miteinander kommunizieren. Die Kommunikation mit dem Atlassian Kernsystem und JIRA ist über eine REST-API oder über Java-APIs möglich.

In Zukunft ist zu erwarten, dass JIRA bzw. Atlassian in weitere Kernprozesse von Unternehmen vordringen wird. So z.B. geschehen mit dem Atlassian-eigenen Plugin “Service Desk”, welches den klassischen IT-Support-Prozess durch die Kombination eines Portals zur Meldung von Vorfällen mit der Verwaltung und Bearbeitung der so gemeldeten Tickets in JIRA abbildet.

Für zukünftige Plugin Generationen bleibt abzuwarten, wie sich das Atlassian Connect Framework entwickelt und wie eine mögliche Version 3 für JIRA Server Plugins aussehen wird.

Lukas Gotter

Lukas Gotter beschäftigt sich leidenschaftlich mit Produktmanagement, Softwareentwicklung, Agilität und Webtechnologien. Darüber hinaus ist er ein versierter Atlassian-Berater und derzeit als Product Owner der Atlassian Marketplace Add-Ons unterwegs.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Weitere Inhalte zu Agile Management

Agile Management

Unbequeme Wahrheiten

Agile Management

Planlos agil

Kommentare

  • Björn Schotte

    Toller Post!

    Den YouTube Videos des Atlassian Summit 2014 ist zu entnehmen, dass Jira Connect „early 2015“ auch für die Server-Instanzen zur Verfügung stehen soll. Es steht also zumindest auf der Roadmap, dies auch für die On Premise Variante zu ermöglichen.

    Was uns natürlich freut, da wir eher in der NodeJS/JS/PHP Welt zu Hause sind als in Java, und Atlassian sich somit nochmal einem weiteren Ökosystem an potenziellen AddOn-Entwicklern öffnen wird.

    • Lukas Gotter

      16. Januar 2015 von Lukas Gotter

      Hi Björn, Danke!

      Ich habe diese Frage auch auf Atlassian Answers gepostet wonach es eher danach geklungen hat dass die beiden Welten (Version2 und Connect) parallell existieren werden.
      Gerade habe ich aber noch diese (neue?) offizielle FAQ gefunden – demnach besteht die Absicht in Zukunft mehr auf connect zu setzen. „our goal is to transition all third-party Plugins 2 add-ons to Atlassian Connect“ – Ob dies gelingt ist aber eine andere Frage ^^

Kommentieren

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