- Erfahrungsbericht zu einem Open-Source-Projekt für die Migration von Jira zu GitLab
- Auslöser
- Ankündigung des Support-Endes für Jira-Server-Produkte zum 15. Februar 2024
- Mögliche Alternativen: Pivotal Tracker, IBM Engineering Requirements Management DOORS Next, Rally Software, GitLab, ServiceNow Agile Development, GitHub usw.
- Was machen Nutzer von Jira Server? Sollen wir ein Projekt für die Migration zu GitLab bauen?
- Stand der Jira→GitLab-Migrationsfunktionen
- GitLab kopiert Titel, Beschreibung und Labels von Jira-Issues
- Die übrigen Metadaten werden in die Beschreibung übernommen
- Eine UI zum Zuordnen von Jira-Usern zu GitLab-Usern wird bereitgestellt
- Einschränkungen bei der Jira→GitLab-Migration
- Die Konfiguration der Jira-Integration ist zwingend erforderlich
- Es wird nur Jira API v3 bereitgestellt
- Jira und GitLab verwenden unterschiedliche Syntax, daher ist keine exakte Migration möglich
- In der Beschreibung werden „Heading 1“, „Heading 2“, „Heading 3“ als „Numbered“, „SubNumbered“, „SubNembered 2“ übernommen
- GitLab verwendet Markdown, Jira hingegen das proprietäre Format „ADF(Atlassian Document Format)“, wodurch diese Unterschiede entstehen
- Auch Issue-Typ, Priorität und Label werden nicht exakt migriert
- Ausrichtung des internen Migrationsprojekts
- Ziele:
- Entscheidung treffen, wohin Jira-Epics und wohin Issues migriert werden sollen
- Konkret festlegen, auf welche Felder in GitLab Jira-Issue-Felder wie title, description, label und component abgebildet werden sollen
- Bei der Migration von Jira-Epics zu GitLab-Epics wird den Nutzern die Freiheit gegeben zu entscheiden, ob sie als Sub-Epics in einer Subgroup oder als Epics in einer übergeordneten Gruppe migriert werden sollen
- Issues werden als Issues migriert
- Grenzen:
- Sub-Tasks sollten eigentlich als Tasks unter einem übergeordneten Issue migriert werden, aber die Task-API von GitLab unterstützt das nicht
- Jira hat zu viele Felder;
- Einfache Funktionen wie description, label und component werden auch von GitLab unterstützt und können migriert werden
- Aber!!! Felder zu time tracking und security werden von GitLab nicht unterstützt und können daher nicht migriert werden
- Endgültiges Zieldesign
- Jira-Projekt → GitLab-Projekt
- Jira-Epic → GitLab-Epic
- Jira-Issue → GitLab-Issue
- title, description, version, story point und resolution aus Jira werden direkt auf GitLab gemappt
- Jira resolution → GitLab closed, Jira story point → GitLab weight
- Jira issue type, component, status, priority → Migration über GitLab-Labels und Scoped Labels
- Auch custom field wurde entwickelt
- description wird vollständig per regulären Ausdrücken geparst und der Inhalt zur Migration in Markdown umgewandelt
- Projektergebnis
- Die Migration im reinen Jira-Standardmodus ist brauchbar
- Ohne Plugins und Automationen funktioniert die Migration gut
- Das meiste wird über GitLab-Labels abgebildet
- Epics werden in der Ziel-Top-Level-Gruppe erstellt
- In Jira verknüpfte Issue-Links werden ebenfalls nach GitLab migriert
- Jira-Wiki-Markup wird mit einem Markdown-Konverter umgewandelt
- Attachments und Kommentare werden den Issues ebenfalls hinzugefügt
- Viele custom fields erschweren die Migration
- Was gut gelungen ist
- Zuerst wurde die Cloud-Version erstellt, danach zusätzlich die Server-Version
- Wenn nur das Mapping der custom fields konfiguriert wird, lässt sich der Großteil migrieren
- Durch geeignete Parallelisierung wurde die Migration mehr als dreimal so schnell wie ohne diese Umsetzung
- Das Konfigurationsmanagement wurde zeitgemäß YAML-basiert umgesetzt
- Als Open Source kann nun jeder Migrationen durchführen
- Das Paket wird über Brew verteilt
- Was verbessert werden sollte
- Bei der Migration aus Jira Server
- Zusätzliches Sprint-Mapping ist erforderlich
- Für Cascade-Felder gibt es keine Lösung
- Bei der Migration aus Jira Cloud
- Es sind Tests für zahlreiche reale Fälle nötig, etwa für die Migration pluginbezogener Daten
- Seite des Open-Source-Projekts:
Noch keine Kommentare.