Migration von Jira zu VSTS: Work Items migrieren

Die Planungstools Jira und VSTS ähneln sich in vielerlei Hinsicht, da sie beide dieselben Probleme lösen sollen. Wie zu erwarten, gehen sie diese Probleme jedoch unterschiedlich an. Dazu gehören beispielsweise leicht abweichende Terminologie und unterschiedliche Implementierungen. Deshalb ist die Migration bestehender Daten nicht so einfach, wie man es sich wünschen würde.

In diesem Blogbeitrag zeigen wir, wie ihr eine Migration von Jira zu VSTS (Visual Studio Team Services) angehen könnt. Außerdem betrachten wir die Erwartungen und Möglichkeiten hinsichtlich der Daten, die ihr erhalten möchtet, sowie einige wichtige Anpassungen für diesen Übergang.

Was müssen wir migrieren?

Sehen wir uns an, was wir beim Wechsel von Jira zu VSTS migrieren möchten:

• Issue-Eigenschaften

• Verknüpfungen zwischen Issues

• Anhänge

• Verbindungen zu externen Artefakten (Builds, Commits)

• Strukturinformationen zu Backlog und Sprints: Wann beginnen und enden Sprints? Welchen Sprints sind welche Elemente zugewiesen? Welche Backlog-Prioritäten gibt es?

• Historische Informationen: Wer hat welches Issue wann erstellt? Wer hat es wann geschlossen? Wann wurde es wieder geöffnet? Wurde gleichzeitig eine Verknüpfung hinzugefügt?

Anpassungen von Workflows und Benennungen

Beide Tools unterstützen umfangreiche Anpassungen – von kleineren Änderungen an den standardmäßigen Prozessvorlagen bis hin zur Definition einzigartiger Prozesse. Unabhängig davon, ob ihr Jira unverändert nutzt oder den Workflow stark angepasst habt: Zunächst solltet ihr eure aktuellen Praktiken betrachten und prüfen, wie sie zu dem passen, was ihr mit VSTS erreichen möchtet. Sehen wir uns als Beispiel einige Unterschiede zwischen den Scrum-Prozessvorlagen in Jira und VSTS an.

Wenn ihr ein Jira-Issue in ein VSTS-Work-Item überführt, müsst ihr zunächst entscheiden, welchen Typ das daraus entstehende Work-Item haben soll.

Unterschiede bei Typen und Hierarchien

Vergleichen wir die beiden Typen:

Abb. 1: Jira-Issue-Typ-Hierarchie

In den Abbildungen oben sehen wir, dass sich nicht nur die Bezeichnungen unterscheiden – beispielsweise entsprechen Jira-Sub-Tasks den VSTS-Tasks –, sondern auch die Semantik in Bezug auf den Workflow der Prozessvorlagen und die UI-Unterstützung. Für VSTS-Features fehlt ein Jira-Äquivalent, und sowohl Jira-Stories als auch -Tasks können als VSTS-Product-Backlog-Item betrachtet werden.

Einige Fragen, die ihr im Hinterkopf behalten solltet:

Plant euer Team, die Portfolio-Management-Funktionen in VSTS zu nutzen? Wie viele Backlog-Ebenen benötigt ihr? Müssen Jira-Story und -Task unterschieden werden?

Unterschiede bei Status

Auch bei den Status unterscheiden sich die Implementierungen:

Die VSTS-Task-Status ähneln den Jira-Status ausreichend, aber wie sieht es mit den PBI-Status aus? To Do könnte sowohl New als auch Approved entsprechen, und In Progress könnte sowohl Approved als auch Committed entsprechen. Dieser semantische Unterschied lässt sich möglicherweise nicht allein durch die Zuordnung von Statusnamen lösen. Außerdem müsst ihr die Sprints für Stories, Tasks und Sub-Tasks überprüfen, die den Status In Progress haben.

Zusätzlich müsst ihr wissen, ob die Jira-Vorlage um weitere Status erweitert wurde. Falls ja: Wofür werden sie verwendet? Gibt es ein VSTS-Äquivalent? Die Antwort auf die letzte Frage kann ein entsprechender Status oder ein völlig anderer Ansatz sein, beispielsweise die Nutzung von VSTS-Test-Cases anstelle des Status Ready for Testing.

Auch Verknüpfungen werden von den beiden Tools unterschiedlich behandelt. Was in Jira ein Epic-Link- und Parent-Feld sein kann, wird in VSTS durch die Link-Typen Parent und Child ersetzt. Einige in Jira häufig verwendete Link-Typen fehlen zudem standardmäßig in VSTS, etwa Blocked by und Caused by.

Anpassungen: Natürlich lassen sich VSTS-Prozessvorlagen umfangreich anpassen, damit sie Jira ähneln. Irgendwann geht es darum, die richtige Balance zwischen Vertrautheit und der vollständigen Nutzung des neuen Tools zu finden. Im Allgemeinen bedeutet das, einige der standardmäßigen VSTS-Konzepte zu übernehmen.

Der erste Schritt bei einer Migration von Jira zu VSTS besteht darin, die aktuellen Arbeitsweisen zu prüfen und zu verstehen – einschließlich ihres Zwecks. Dafür braucht ihr ein gutes Verständnis davon, was VSTS bietet. Anschließend könnt ihr eure Arbeitsweisen so anpassen, dass sie besser zum neuen Tool passen.

Vor diesem Hintergrund können wir die passende VSTS-Vorlage auswählen und anschließend entscheiden, ob und wie wir sie anpassen möchten. Danach definieren wir die erforderlichen Zuordnungen und Transformationen zwischen Jira- und VSTS-Entitäten, -Namen und -Werten.

Im Basisszenario geht es vor allem darum, Folgendes zuzuordnen:

1. Issue-Typen

2. Link-Typen

3. Status

4. Messfelder (z. B. Priorität, Story Points, Aufwand, verbleibende Arbeit)

5. Backlog-Organisation, etwa Sprint-Zuordnungen und Priorisierung

Implementierung der Migration von Jira zu VSTS

Glücklicherweise bieten sowohl Jira als auch VSTS APIs, auf deren Basis wir den Prozess automatisieren können.

Unserer Erfahrung nach besteht die größte Herausforderung beim Umstieg von Jira auf VSTS darin, die Historie wiederherzustellen und nachzubilden. Jira ermöglicht den Zugriff auf Änderungen an Feldern, Links und Anhängen. Zusammen mit dem API-Endpunkt für den Zugriff auf Kommentare können wir so die Historie eines Elements Änderung für Änderung nachbilden.

Herausforderungen

Die Wiederherstellung der Historie und das Nachbilden von Änderungen auf diese Weise bringen einige Herausforderungen mit sich:

• Wir müssen die von VSTS erzwungenen Regeln ignorieren (API-Option), um Änderungen anwenden und einen anderen Benutzer imitieren zu können. Das wirkt sich subtil darauf aus, wie gut das Tool diese kleinen Tricks in der UI oder in Berichten erkennt und darstellt. Da die unterstützten Workflow-Regeln nicht immer identisch sind, wird dies besonders wichtig.

• Anhänge und andere Artefakte aus früheren Änderungen sind möglicherweise nicht mehr verfügbar.

• Jira verwendet eine andere API für den Zugriff auf gerenderte Felder. Das bedeutet, dass wir Änderungen an diesen Feldern nachbilden können, jedoch nur der aktuellste Stand wie in Jira gerendert wird.

Wir müssen die von VSTS erzwungenen Regeln ignorieren (API-Option), um Änderungen anwenden und einen anderen Benutzer imitieren zu können. Das wirkt sich subtil darauf aus, wie gut das Tool diese kleinen Tricks in der UI oder in Berichten erkennt und darstellt. Da die unterstützten Workflow-Regeln nicht immer identisch sind, wird dies besonders wichtig.

Anhänge und andere Artefakte aus früheren Änderungen sind möglicherweise nicht mehr verfügbar.

Jira verwendet eine andere API für den Zugriff auf gerenderte Felder. Das bedeutet, dass wir Änderungen an diesen Feldern nachbilden können, jedoch nur der aktuellste Stand wie in Jira gerendert wird.

Wenn es Links zu externen Artefakten gibt, müssen diese von VSTS aus zugänglich sein, damit die UI-Integration auf demselben Niveau bleibt. Wenn ihr einen Link zu einem Commit in einem Bitbucket-Git-Repository habt, müsst ihr auch das Repository selbst zu VSTS migrieren, wenn ihr aus einem migrierten Work Item darauf verlinken möchtet. Andernfalls bleibt es einfacher Text – was möglicherweise ein akzeptabler Kompromiss ist.

• Rechnet damit, dass Änderungen an bestimmten Feldern Änderungen in anderen Feldern auslösen können – etwa bei den Feldern Status und Grund. Diese nachzubilden kann angesichts möglicher Änderungskombinationen komplex werden.

Zusammenfassung

Trotz der Herausforderungen und einiger Kompromisse lässt sich bei einer Migration von Jira zu VSTS eine gute Genauigkeit erreichen. Eine Möglichkeit besteht darin, die migrierten Elemente zunächst mithilfe von Areas vom Rest des Projekts zu isolieren. Das ermöglicht manuelle Massenbearbeitungen sowie eine teilweise oder schrittweise Migration der Projektdaten. Die größte Herausforderung ist jedoch nicht die Datenmigration selbst, sondern die Anpassung der Workflows für die Prozessverfolgung in den Teams.

Wenn ihr die Migration selbst durchführen möchtet, folgt einfach dem oben beschriebenen Vorgehen. Falls ihr auf Probleme oder Herausforderungen stoßt, sprecht uns gerne an. Wir bei Solidify verfügen über Expertise und Fachwissen in beiden Systemen und helfen euch gerne weiter.

Mit welchem System arbeitet ihr? Habt ihr über eine Migration von einem System zum anderen nachgedacht? Lasst es uns in den Kommentaren unten wissen!