Atlassian Jira als Aufgabenmanagement-Tool wird in mehr als 100.000 Unternehmen weltweit eingesetzt.

Aus diesem Grund ist es nicht ungewöhnlich, dass ein einzelnes Unternehmen zwei oder mehr Jira-Installationen verwaltet. Um Kosten zu sparen, kann es erforderlich sein, diese Installationen zu einer einzigen zusammenzufassen. In den folgenden Zeilen beschreiben wir, wie wir die Konsolidierung von Jira-Instanzen bei einem unserer Kunden durchgeführt haben.

Über den Kunden

Unser Kunde in diesem Projekt war ein weltweit führendes Unternehmen im Bereich der Technologie für die Messung von dynamischem Druck, Kraft, Drehmoment und Beschleunigung. Die einzigartige Sensor-Technologie dieser von ihren Eigentümern geführten schweizerischen Korporation trägt nicht nur zur Gestaltung zukünftiger Innovationen in der Automobilentwicklung und industriellen Automatisierung bei, sondern auch in vielen aufstrebenden Branchen. Das Unternehmen selbst hat Niederlassungen an 60 Standorten weltweit.

Herausforderung – Zusammenführung von zwei Jira-Umgebungen zu einer einzigen

Das genannte Unternehmen hat ein kleineres deutsches Unternehmen übernommen. In beiden Unternehmen wurde Jira als Werkzeug zur Entwicklungskontrolle verwendet. Die Geschäftsleitung traf die Entscheidung, die beiden Jira-Installationen zu einer zu vereinen. Die Zielinstallation wurde von der Konzernzentrale verwaltet. Die Anforderung umfasste den Transfer aller Jira-Projekte, einschließlich der Einstellungen (Workflows, Felder, Bildschirme usw.). Die Projekte mussten auch zusammen mit Aufgaben, Anhängen und aufgewendeter Zeit für die Aufgaben übertragen werden. Selbstverständlich war es erforderlich, die Benutzerberechtigungen für einzelne Projekte beizubehalten.

Neben anderen Funktionen wurde die Quell-Jira auch für die Erfassung von Kundeninkidenten in Jira Service Management (JSM) genutzt. Die Ziel-Jira enthielt kein Jira Service Management, daher war es notwendig, JSM hinzuzufügen und es genauso einzurichten wie in der Quell-Jira.

Analyse

Vor der eigentlichen Migration war eine gründliche Analyse erforderlich. Im ersten Schritt wurde die Benutzerverwaltung analysiert, um sicherzustellen, dass die Benutzer dieselben Anmeldeinformationen haben. In unserem Fall wurden Benutzer aus dem Active Directory (AD) in der Quell-Jira gelesen, daher musste die Verbindungseinstellung zum AD auch in die Zielumgebung übertragen werden.

Ein weiterer wichtiger Teil der Analyse war die Untersuchung von Anwendungen. Wir mussten herausfinden, welche Erweiterungen in der Quellinstallation aktiv verwendet wurden, und anschließend die Möglichkeiten für ihren Ersatz in der Zielinstallation feststellen. Wenn eine Anwendung nicht ersetzt werden konnte, musste sie in die Ziel-Jira installiert werden.

Für den eigentlichen Datenexport (Projekte, Aufgaben, Anhänge usw.) haben wir uns entschieden, die Erweiterung „Configuration Manager for Jira„ zu verwenden. Diese Erweiterung kann alle Konfigurationselemente eines Jira-Projekts erfassen und sie dann in einen Snapshot exportieren. In den Exporteinstellungen können Sie festlegen:

Exportierte Projekte

• Aufgaben des Projekts exportieren
• Auch mit Anhängen exportieren
• Die Erweiterung muss in beiden Instanzen installiert werden.

Ein Vorteil der Erweiterung besteht darin, dass sie nur für 30 Tage (anstatt des traditionellen Jahres) erworben werden kann, wodurch die finanziellen Mittel des Auftraggebers gespart werden können.

Später haben wir drei spezifische Jira-Projekte identifiziert, die im Rahmen der Testmigration in die Testumgebung migriert wurden und deren Funktionalität anschließend getestet wurde. Die Projekte waren unterschiedlicher Art (Teamprojekt mit internen Aufgaben, Entwicklungsprojekt mit Scrum-Board und JSM-Projekt mit Formularen im Portal), um einen möglichst großen Teil der Funktionalität abzudecken. Die Auswahl der Projekte erfolgte in Zusammenarbeit mit den Auftraggebern.

Das übernommene Unternehmen stammte aus Deutschland und verwendete vorkonfigurierte Felder (wie z. B. Epic-Name, Epic-Status usw.) in deutscher Sprache, während der Käufer als weltweit tätiges Unternehmen diese Felder in Englisch nutzt. Da der Configuration Manager die Namen entsprechend der Quell-Jira ersetzt hätte, mussten diese Felder umbenannt werden. Eine weitere wichtige Sache war zu überprüfen, ob dieselben Schema-Namen verwendet wurden (Berechtigungsschema, Benachrichtigungsschema usw.).

Wenn die Schemata gleich benannt sind und unterschiedlich konfiguriert sind, würde das Schema in der Ziel-Jira gemäß der Konfiguration in der Quell-Jira überschrieben werden. In unserem Fall haben wir ein Benachrichtigungs- und ein Berechtigungsschema in der Quell-Jira umbenannt.

Die Migration selbst

Vor der eigentlichen Migration haben wir den Import der genannten drei Projekte in die Testumgebung durchgeführt, die identisch mit der produktiven Zielumgebung war. Während des Imports haben wir den Ablauf der Migration in die produktive Umgebung verfeinert. Wie es bei Migrationen üblich ist, überträgt das Migrationswerkzeug nicht alles zu 100 %, und nach dem Import waren einige manuelle Anpassungen an den konfigurierten Projekten erforderlich. In unserem Fall handelte es sich um Post-Funktionen (Veröffentlichungsfunktionen) aus einer Erweiterung, die vom Configuration Manager nicht unterstützt wurde.

Die eigentliche Migration erfolgte in den folgenden Schritten:

• Export von Daten aus der Quellumgebung
• Übertragung von Daten vom Server der Quell-Jira auf den Server der Ziel-Jira
• Vorbereitung der Zielumgebung (Installation von Erweiterungen, Konfiguration der AD-Verbindung, Installation von Jira Service Management)
• Import von Daten in die Zielumgebung
• Durchführung von Einstellungen für Projekte, die der Configuration Manager nicht übertragen kann
• Funktionsprüfung

Es war selbstverständlich, vor Beginn der Migration eine Sicherung der Zielumgebung zu erstellen. Insgesamt konnten wir innerhalb eines Wochenendes die Jira-Umgebungen konsolidieren.

Vorteile

Der Hauptvorteil der Konsolidierung besteht darin, dass alle Mitarbeiter in einer Jira-Installation arbeiten. Der nächste Schritt wird die Vereinheitlichung der Prozesse des Unternehmens und des übernommenen Unternehmens sein – in einer Installation ist ein solcher Prozess einfacher. Für die Benutzer des übernommenen Unternehmens hat sich nur die URL des Systems geändert. Einsparung von Kosten für die Verwaltung und Lizenzierung von zwei Jira-Umgebungen – Zeit für die Optimierung von Jira wird gespart. Verbesserung der Zusammenarbeit der Mitarbeiter – ein Mitarbeiter muss nicht zwischen 2 Umgebungen wechseln, sondern kann alles in einer Jira finden. Diese Verbindung der beiden verschiedenen Instanzen haben wir innerhalb von 2 Monaten gemeistert.

Wenn Sie Unterstützung von Experten bei der Einführung oder Konfiguration von Jira benötigen oder Tipps zur effektivsten Nutzung in Ihrem Unternehmen benötigen, zögern Sie nicht, uns zu kontaktieren.

Unsere Atlassian-Lösungen