JIRA ist längst nicht mehr nur ein Werkzeug für Softwareentwicklungsabteilungen. Die Software des Herstellers Atlassian wird in immer mehr Unternehmen für Business-Prozesse eingesetzt und durch den vielfältigen Einsatz zu einer Business-kritischen Anwendung. Deshalb ist es sinnvoll, neben der produktiv eingesetzten JIRA-Instanz auch min. eine zusätzliche Testinstanz zu betreiben, um gewünschte Änderungen zuvor ausreichend testen zu können.
Doch diese Änderungen können durchaus sehr umfangreich sein und schnell > 100 Konfigurationseinstellungen umfassen. Viele Unternehmen übertragen diese Konfiguration dann manuell in die produktive Umgebung.
Dieses Vorgehen ist nicht nur sehr zeitaufwändig, sondern auch sehr fehleranfällig.
Doch welche Unterstützung bietet JIRA, um Konfigurationsänderungen effizienter in Produktionsumgebungen zu übertragen?
Auf diese Frage und auf die Erweiterung durch das Plugin „Configuration Manager“ möchte ich in diesem Blogeintrag eingehen.
Das JIRA Backup
Der einfachste Weg, eine vorhandene JIRA-Instanz in eine andere zu übertragen, ist sicherlich ein Backup. Den Backup Manager findet man in den Systemeinstellungen im JIRA-Adminbereich. Für ein vollständiges Backup wird allerdings nicht das XML-Backup von JIRA empfohlen, sondern der konsistentere Weg über die nativen Datenbank-Backuptools. Will man nicht das komplette System übertragen, kann man über den XML-Import einzelne Projekte aus dem Backup in die Zielinstanz einspielen.
Spätestens, wenn man die Daten der Zielinstanz unverändert lassen möchte, ist allerdings das Vorgehen über ein Backup keine Lösung mehr.
Eine voll umfassende Lösung, ohne alle vorhandenen Daten zu überspielen, ist leider nicht vorhanden.
Workfows übertragen
Für Workflows stellt JIRA eine Übertragungsmöglichkeit zur Verfügung. Mit Administratorrechten ausgestattet, lassen sich Workflows nicht nur lokal exportieren, sondern auch direkt in den Atlassian Marketplace stellen, um den Workflow mit der JIRA-Community zu teilen.
Die Export-Datei kann dann in der neuen Instanz importiert werden.
Weiteren Infos hierzu in der Atlassian-Dokumentation .
Weitere Übertragungsmöglichkeiten bringt JIRA nicht mit, auch wenn es für den Export/Import von Konfigurationseinstellungen schon seit über 10 Jahren einen Feature-Request gibt und dieser mit zu den meistgefragten Feature-Requests überhaupt gehört.
Atlassian verweist in dem genannten Ticket auf Hersteller von Plugin-Erweiterungen.
Hier wird unter anderem der „Configuration Manager “ (Botron Software) genannt, aber auch der Hersteller von Awnaba Software mit dem „Project Configurator “ sowie der „Spectrum – Process Manager“ von Clearvision.
Der Configuration Manager
Auf die Erfahrungen, die ich mit dem „Configuration Manager“ gemacht habe, möchte ich hier detaillierter eingehen.
Das Prinzip des Configuration Managers beruht auf Snapshots. Ein Snapshot beschreibt den Zustand der Konfigurationsobjekete einer JIRA-Instanz zu einem gegebenen Zeitpunkt.
Der Configuration Manager unterscheidet zwischen System- und Projektkonfigurationssnapshots. Ein Systemsnapshot beinhaltet alle Projekte der Instanz inklusive deren Konfigurationen, nicht jedoch globale Systemeinstellungen, wie der Name leicht vermuten lässt. Ein Projektsnapshot exportiert exakt ein ausgewähltes Projekt und dessen Konfiguration.
In unseren Projekten nutzten wir bisher immer die Projektkonfigurationssnapshots.
Die Bedienung des Configuration Managers ist sehr intuitiv und eingängig. Nach erfolgreicher Installation des Plugins erscheint für den Administrator der JIRA-Instanz ein neuer Menüpunkt unterhalb der Systemeinstellungen.
Im ersten Schritt wählt man aus, ob ein Systemsnapshot oder ein Projektsnapshot erstellt werden soll. In unserem Fall haben wir ein Projektsnapshot erzeugt.
Allen Snapshots muss noch ein eindeutiger Name gegeben werden.
Neben einer Übersicht zu allen erzeugten Snapshots bietet der Configuration-Manager zudem eine „Audit“-Funktion, bei der ebenfalls alle Änderungen bzgl. der Snapshots aufgezeichnet werden. Dies ermöglicht jederzeit den Einblick, wer wann wo einen Snapshot erstellt oder deployed hat.
Wurden einmal alle Konfigurationen erfolgreich im Snapshot abgelegt, geht es im nächsten Schritt um das Deployment der Konfiguration.
Tipp: Wer diese Software zum ersten Mal ausprobiert, sollte immer vorher ein Backup des Systems durchführen. Später muss natürlich nicht zwingend vor jedem Deployment ein Backup erzeugt werden.
Snapshots können auf drei unterschiedliche Arten deployed werden. Dabei wird das Deployment-Artefakt:
- innerhalb derselben Instanz benutzt
- von einer verlinkten JIRA-Instanz (Voraussetzung: Application Link zu dieser Instanz ist eingerichtet)
- über ein Zip-File, das zuvor von der Ausgangsinstanz erzeugt und im Dateisystem abgelegt wurde.
Im zweiten Step analysiert das Plugin die Zielumgebung. Die Konfigurationen werden verglichen und Abweichungen als Fehler oder Warnungen reportet. In unserem Projekt wurde so z.B. automatisch erkannt, welche Plugins im Zielsystem gefehlt haben. Auch redundante Custom Fields (so etwas soll ja mal vorkommen 😉 ) wurden erkannt und als Fehler gemeldet.
Sind alle erkannten Fehler behoben, kann das Deployment an sich gestartet werden.
Als ich das erste Deployment mit dem Configuration Manager durchgeführt habe, wollte ich natürlich wissen, ob auch wirklich alle Konfigurationen übernommen wurden. Das war dann zwar kein unerheblicher Aufwand – hat mir dann aber die Gewissheit für die zukünftigen Deployments gegeben.
Unterstützte Configuration Objects
Aus den gemachten Erfahrungen kann ich sagen, dass die folgenden Objekte unterstützt werden:
- Issuetypes
- Workflows
- Screens
- Fields inkl. Customfields
- Filter
- Rollen
- Benutzer
- sogar Bedingungen, Bestätigungen und Folgefunktionen aus Dritthersteller-Plugins
Natürlich wurden zu den Objekten auch die Schemata übernommen und dem Projekt zugeordnet.
Nicht unterstützt wurden:
- Agile Boards
- Dashboards
Ein nicht reproduzierbares Problem (und damit auch nicht zwingend dem Configuration Manager zuzuordnen) gab es nach dem allerersten Deployment. Dabei wurde ein User, den es bisher nur im Ausgangssystem gab, im Zielsystem angelegt. Leider ließ sich der User nicht bearbeiten – auch nicht löschen. Ein Aufräumen des JIRA-Cache konnte das Problem dann beheben. Glückliche Besitzer des Script-Runner-Plugins können das z.B. ganz einfach über das Build-In Script „Clear classloader or jira internal caches“ tun.
Integrity Check
Als ebenfalls nützliches Feature hat sich der Integrity Check (im Configuration-Manager-Plugin enthalten) herausgestellt. Auch wenn die Integritätsprüfung über die gesamte Instanz läuft und nicht projektweise durchführbar ist, geben die Meldungen gute Hinweise auf offene Konfigurationsbaustellen.
Zu jedem gefundenen Fehler wird gleichzeitig auch ein Lösungsvorschlag aufgelistet.
Fazit:
In den bisher eingesetzten Projekten hat sich der Configuration Manager als echter „Time Saver“ bewährt. Klar ist: Je höher der zu übertragende Konfigurationsaufwand, desto schneller macht sich auch der stolze Preis dieses Plugins bezahlt. In unseren Projekten hat sich das Plugin allerdings schon nach dem zweiten Deployment rentiert.
Betrachtet man nicht nur die reine Arbeitszeit zur Übertragung, sondern auch z.B. die dadurch minimierte „Downtime“ bzw. „Frozen-Time“ der Zielumgebung, ergeben sich weitere Pluspunkte.
Viele Unternehmen neigen dazu, gerade kleine Änderungen in JIRA schnell mal manuell in der produktiven Umgebung durchzuführen. Testumgebung und Produktionsumgebung driften in ihrer Funktionalität dann immer weiter auseinander. Sollen dann Änderungen tatsächlich wieder erst in der Testumgebung durchgeführt werden und danach wieder in die Produktivumgebung übernommen werden, sind Fehler vorprogrammiert.
Ein konsistenter und mit wenig Aufwand verbundener Ausweg ist es, Deployments immer automatisiert von Test nach Produktion mit z.B. dem hier vorgestellten Plugin durchzuführen.
War dieser Beitrag hilfreich?
Weitere Beiträge
von
31.3.2021 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.