Projektmigration in Jira leichtgemacht

Heute möchte ich dir den „Project Configurator“ vorstellen.

Wir benutzen den „Project Configurator“ als Tool zur Unterstützung bei der Projektmigration. Die App kann aber auch dabei unterstützen, eine Konfiguration, zum Beispiel von einem Staging System, in die Produktion zu übernehmen.

Im Großen und Ganzen besteht der Vorgang aus zwei Schritten: Zuerst exportiere ich Daten aus dem einen System und bekomme dann entweder eine ZIP- oder XML-Datei. Danach kann ich diese im Zielsystem importieren.

Ich gehe auf die einzelnen Schritte jetzt noch etwas detaillierter ein.

Wenn du die App installiert hast, findest du im Bereich „Apps verwalten“ im Menü auf der linken Seite im Abschnitt „Project Configurator“ den Menüpunkt „Export Projects“.

Nachdem du diesen ausgewählt hast, wird dir die Maske für die Konfiguration des Exports angezeigt. Dort kannst du Projekte auswählen, die du exportieren möchtest. Außerdem kannst du entscheiden, ob nur die Konfiguration oder das ganze Projekt exportiert wird. Wenn du das gesamte Projekt auswählst, bekommst du eine weitere Drop-Down-Box, mit der du steuern kannst, ob die Anhänge mit in die ZIP-Datei exportiert werden sollen („Automatic“) oder ob du diese händisch auf das andere System kopierst („Manual“). Letzteres kann dir viel Zeit bei der Migration sparen, weil Export, Transfer des ZIPs und Import deutlich weniger Zeit kosten, da die Datei viel kleiner ist. Insbesondere bei Projekten mit vielen oder großen Anhängen können Probleme bei der ZIP-Generierung entstehen, wenn auch die Anhänge exportiert werden sollen. Es kann zu Timeouts kommen und die ZIP-Datei wird nicht vollständig erzeugt.

Danach kannst du aus mehreren Möglichkeiten wählen, was alles in den Export mit rein soll. Zuerst kannst du entscheiden, ob du alle benutzerdefinierten Felder oder nur die im Projekt benutzen Felder exportiert werden sollen.

„Im Projekt benutze Felder“ bedeutet, dass diese entweder

• in einem Schema (Berechtigung, Benachrichtigung, Vorgangssicherheit),
• oder in einem Workflow
• oder in der Feld-Konfiguration als sichtbar
• oder in einer Bildschirmmaske verwendet werden
• oder irgendein Vorgang einen Wert für dieses Feld enthält.

Beim Export besteht die Möglichkeit, die Prüfung auf die Werte der benutzerdefinierten Felder wegzulassen, dann greifen nur die anderen Regeln.

Dies ist eigentlich dazu gedacht, bei großen Instanzen die Prüfung auf die Werte in der Datenbank zu verkürzen. Es kann aber auch helfen, wenn du in einer historisch gewachsenen Umgebung bist und eventuell noch Datenleichen in der Datenbank hast, diese an der Stelle herauszufiltern.

Als nächstes kannst du steuern, ob alle Benutzer, nur die gültigen oder gar keine Benutzer mit exportiert werden. Die gleichen Optionen hast du auch für die Benutzergruppen.

Bei den gespeicherten Filtern hast du relativ viele Auswahlmöglichkeiten für den Export. Zur Auswahl stehen:

• keine Filter,
• •nur die Filter, die mit allen geteilt werden,
• nur die Filter, die mit dem exportierten Projekt geteilt werden,
• Filter, die mit allen Benutzern oder dem exportierten Projekt geteilt werden,
• alle geteilten Filter oder einfach alle existierenden Filter.

Aus unserer Erfahrung heraus ist es oft schwierig, Filter zu exportieren. Diese beziehen sich häufig auf mehr als ein Projekt und können somit nicht mehr sinnvoll importiert werden. Daher versuchen wir, so wenig Filter wie möglich über den Export mitzunehmen und diese hinterher passend für die Zielumgebung neu anzulegen.

Für die Dashboards hast du wieder die gleichen Optionen wie für die Filter. Auch gelten hier die gleichen Einschränkungen und Anmerkungen.

Als letztes hast du die Möglichkeit zu entscheiden, welche agilen Boards exportiert werden sollen. Dabei hast du die Wahl zwischen keine Boards, Boards, die mit dem exportierten Projekt verknüpft sind oder alle Boards.

Wenn du regelmäßig die gleiche Konfiguration benötigst, kannst du diese hier abspeichern.

Wenn du nun exportierst, bekommst du eine entsprechende Datei zum Download. Diese kannst du im Ziel-System hochladen.
Für den Import wählst du dann links im Menü den Punkt „Import Projects“ aus.

Hier hast du erneut die Möglichkeit zu wählen, ob du nur die Konfiguration oder ein ganzes Projekt importierst. Darunter kannst du die Datei auswählen und hochladen. Wählst du hier das ganze Projekt aus, hast du gleichzeitig die Möglichkeit, auch eine Import-Datei auf dem Server auszuwählen. Wenn du das tust, kannst du den Pfad auf dem Server angeben, wo die Anhänge liegen. Jira muss auf diesen Pfad natürlich zugreifen können, damit der Import funktioniert.

Jetzt stehen dir einige Optionen zur Verfügung, die du auswählen kannst:

• Soll eine Simulation des Imports durchgeführt werden? Das ist standardmäßig angehakt. Wir empfehlen, dies so zu belassen.
• Sollen benötigte Projekte angelegt werden? Auch das ist standardmäßig angehakt und sollte so bleiben. Damit werden bei Bedarf Projekte angelegt, die einfach nur existieren müssen. Du kannst diese in der Regel hinterher problemlos wieder löschen, aber so kommst du zumindest durch den Import durch.
• Adaptieren des Kontextes der benutzerdefinierten Felder: Das ist standardmäßig nicht ausgewählt. Wir empfehlen jedoch, diesen Punkt anzuklicken. So wird ein eigener Kontext für das importierte Projekt angelegt. Das verhindert Änderungen der Konfiguration für die bestehenden Projekte.
• Daten Import aus verschiedenen Jira Versionen: Diese Option ist nicht automatisch ausgewählt und sollte ohne guten Grund auch nicht ausgewählt werden. Denn verschiedene Jira Versionen bereiten potenziell Probleme. Du solltest dies nur tun, wenn kein Weg daran vorbeiführt.

Zum Abschluss hast du noch die Möglichkeit, verschiedene Bereiche der Konfiguration vom Import auszuschließen.

Wenn du den Import startest, wird zunächst die Import-Datei validiert und der „Project Configurator“ stellt dir eine Übersicht mit allen Änderungen bereit, die beim Import durchgeführt werden. Dabei wird bei jeder Änderung angezeigt, ob es die Änderung einer bestehenden Konfiguration oder eine neue Konfiguration ist und ob es vielleicht ein Problem bei der Konfiguration gibt. Hier kannst du auch gezielt jede einzelne Konfigurationsänderung wieder ausschalten.

Wenn du den richtigen Import startest, heißt es warten und Daumen drücken. Am Ende gibt es ein Log, in dem alle Änderungen aufgeführt werden, sowie eine Übersicht, ob der Import erfolgreich war oder nicht. Gegebenenfalls musst du die Ausgangsdaten in der Quell-Instanz anpassen und das ganze Spiel geht von vorne los.

Es ist hilfreich, nach der Migration das Audit-Log zu checken. Dort siehst du die meisten relevanten Änderungen und kannst prüfen, ob vielleicht eine ungewünschte Konfiguration migriert wurde, die dann händisch korrigiert werden muss.

Wenn ihr Fragen oder Beratungsbedarf zum Einsatz der App habt, meldet euch gerne bei uns: atlassian@team-neusta.de