Migration von IBM Rational Synergy zu Git

Die Geschichte von IBM Rational Synergy

IBM Rational Synergy ist ein client-server-basiertes Versionskontrollsystem, das sich von einem System zur Versionskontrolle einzelner Dateien in den 90er-Jahren zu einem Aufgabenmanagementsystem mit einem darauf aufbauenden Änderungsmanagementsystem namens Change entwickelt hat. Im Laufe der Jahre wurde es unter verschiedenen Namen (Continuus, CM/Synergy und zuletzt Rational® Synergy) und von unterschiedlichen Unternehmen vertrieben, bis es schließlich unter der Marke Rational® bei IBM® landete.

In den 2000er-Jahren hatte es einige Stärken, die ihm zu Marktakzeptanz verhalfen. Erstens ist es ein aufgabenbasiertes Konfigurationsmanagementsystem und damit einen Schritt weiter als Systeme wie CVS. In Synergy könnt ihr Entwicklern Aufgaben zuweisen, die Datei-Revisionen ändern und hinzufügen und die Aufgabe schließlich für ein bestimmtes Release abschließen.

Zweitens verfügt es über das Konzept von Repositories, das sich besonders für größere Unternehmen eignet, in denen viele Teams Komponenten für Produktlinien bereitstellen.

Drittens ließ es sich mit Rational Change erweitern, um Prozesse für das Software-Änderungsmanagement sowie angepasste Hierarchien, Eigenschaften und Lebenszyklen zu implementieren.

IBM Rational Synergy nähert sich dem Ende seines Lebenszyklus

Das Tool wird zwar gewartet, hat aber seit vielen Jahren keine funktionalen Updates erhalten und nähert sich daher seinem Lebensende. Allein aus diesem kritischen Grund sollte eine schnelle Migration zu einem neuen System wie Git auf der IT-Agenda stehen.

Darüber hinaus ist das System sehr langsam in der Nutzung, erfordert für einfache Merges viel manuelle Arbeit, ist für langlebige Release-Branches ausgelegt und komplex zu verstehen. All das kann die Effizienz von Entwicklungsteams beeinträchtigen.

Meiner Erfahrung nach entwickeln Teams und Unternehmen eine „Finger weg“-Mentalität. Das bedeutet, dass sie nicht einmal ihre Nutzung von Synergy weiterentwickeln oder optimieren, um die Anforderungen der Teams zu erfüllen. Sie leben damit und finden Workarounds. Schon das allein zeigt, dass es Zeit ist, weiterzuziehen.

Die große Frage lautet: Ist das machbar? Die kurze Antwort: „Mit hoher Wahrscheinlichkeit.“ Es hängt wirklich davon ab, wie Synergy über die Jahre genutzt wurde.

Die Migration planen

Die Datenmodelle von Synergy und Git abgleichen

Synergy verfügt über ein sehr flexibles Modell dafür, wie Softwareänderungen eine Revision bilden. Das stellt bei der Migration von Synergy zu Git eine Herausforderung dar. Die Datenmodelle sind völlig unterschiedlich. Dies sind die wichtigsten Unterschiede.

Überblick über die Zuordnung der Konzepte

Auf Grundlage unserer Migrationserfahrungen haben wir eine Migrationsstrategie entwickelt, die in der folgenden Tabelle zusammengefasst ist. Sie enthält zunächst eine kurze Einschätzung und anschließend eine detaillierte Begründung.

Synergy

Git

Dateien und Historie

Nicht direkt

Aufgaben

Nicht direkt

Baselines

Nicht direkt

Releases

Nein

Projekte und Revisionen

Repository, Commits und Tags

Unterprojekte

Submodule

Benutzerdefinierte Attribute

Nein

Dateien und ihr Verlauf – nicht direkt migriert

Dateien in Synergy haben einen eigenen Revisionsverlauf und könnten für die Migration interessant sein. In Git existieren Dateirevisionen jedoch nicht als eigenständige Revisionen.

Synergy-Dateiobjekte haben Typen, auf deren Grundlage Dateien unterschiedliche Zeilenumbrüche sowie unterschiedliches Verhalten bei Anzeige und Merges haben können. Dies lässt sich weitgehend in .gitattributes umsetzen. Explizit behandelt werden müssen jedoch die Ausführungsbits, da sie in Git nicht automatisch gesetzt werden.

Beachtet bestehende .gitignore- und .gitattributes-Dateien im importierten Quellcode, da sie während der Migration zu unbeabsichtigtem Verhalten führen können. Merges werden auf Ebene der Dateiobjekte durchgeführt.

Tasks – nicht direkt migriert

Tasks wären das ideale Migrationsobjekt, da sie einer einzelnen Änderung ähneln, wie eine Patch-Datei in Git. Das bedeutet, dass sie keine Parent-Beziehung haben. Sie werden nicht migriert, aber in Commit-Nachrichten und annotierten Tags aufgeführt.

Baselines – nicht direkt migriert

Baselines, auch Baseline-Objekte genannt, können nicht als solche migriert werden, da sie lediglich Metadaten-Container und Verknüpfungen zu Projektrevisionen, Tasks und Change Objects sind. Das Nächstliegende in Git sind annotierte Tags; die Baseline-Informationen werden als Annotation hinzugefügt. Baselines sind ein relativ neues Konzept und erst seit Version 7.x verpflichtend, daher sind sie keine verlässliche Quelle für die Migration.

Releases – nicht migriert

Releases ähneln in gewisser Weise Branches, werden jedoch üblicherweise als langlebige Release-Branches verwendet. Sie erscheinen nur in der Benennung des annotierten Tags.

Projekte und Projektrevisionen – migriert

Projekte und Projektrevisionen in einem statischen Zustand entsprechen am ehesten einem Commit in Git. Die statischen Zustände von Projektrevisionen sind: integrate, test, sqa und released. Dabei handelt es sich um eine reproduzierbare Revision, die auf einer vorherigen Revision basiert, der sogenannten Projekt-Baseline. Projektrevisionen sind die besten Migrationsobjekte, da sie die Revision des Quellcodes enthalten und die Beziehung zum Verlauf abbilden.

Ein Synergy-Projekt sollte standardmäßig einem Git-Repository zugeordnet werden. Der Revisionsname entspricht in der Regel dem Release, der Build-Nummer oder einer ID, die die Softwareorganisation später wieder zuordnen kann. Revisionsnamen oder IDs werden Git-Tags zugeordnet. Nach der Migration könnt ihr die entsprechende Software-Revision in Git unter derselben Bezeichnung finden wie in Synergy.

Für Projektnamen und Revisionen gelten deutlich weniger Einschränkungen als für die Benennung von Git-Repositories und -Tags. Daher müsst ihr Leerzeichen und Sonderzeichen wahrscheinlich durch Bindestriche oder Unterstriche ersetzen und Projektnamen vermutlich einheitlich kleinschreiben.

In Synergy können mehrere Projekte denselben Namen haben; unterschieden werden sie über das Instanzattribut. Wie diese migriert werden, sollte sich danach richten, warum doppelte Projektnamen existieren. Möglicherweise handelt es sich im Repository Manager um unterschiedliche Projekte, oder der Verlauf aller Instanzen gehört in dasselbe Ziel-Git-Repository.

Auf Ebene der Projektrevisionen gibt es kein Konzept für Merges, da eine Projektrevision nur ein Parent-Element haben kann.

Falls die Projektrevisionen keine Revisionen, Builds oder Releases abbilden oder gar nicht existieren – schließt das eine Migration aus?

Nein, nicht unbedingt. Softwareorganisationen haben in der Regel Release Notes oder Stücklisten. Darin sind die Baseline-Revision, Unterprojektrevisionen und Task-Listen aufgeführt. In diesem Fall lässt sich die Revision rekonstruieren und nach Git migrieren.

Unterprojekte – migriert

Sie lassen sich direkt auf Submodule in Git abbilden, da das Datenmodell identisch ist. Einem Projekt kann ein anderes Projekt in einer bestimmten Revision als Unterprojekt hinzugefügt werden. Dadurch entsteht ein Verzeichnis im Workspace. In Git ist es genauso.

Benutzerdefinierte Attribute – nicht migriert

Sie können für jedes Objekt in der Synergy-Datenbank erstellt werden. Sie geben dem Entwicklungsprozess eine besondere Bedeutung, die sich in Git nur schwer nachbilden lässt. Das betrifft weniger die Migration selbst als vielmehr die Frage, wie der Entwicklungsprozess an die Arbeit mit Git angepasst wird.

Das Obige sollte zeigen: Auch wenn es keine Eins-zu-eins-Abbildung von Synergy auf Git gibt, könnt ihr sinnvolle Entscheidungen treffen, die eine Migration ermöglichen.

So migriert ihr

Da Projekte und ihre Revisionen die Einheiten der Migration sind, schauen wir uns genauer an, wie die Migration durchgeführt wird.

Projekte

Zunächst müsst ihr festlegen, welche Projekte aus welchen Datenbanken ihr migrieren möchtet. Vielleicht habt ihr bereits eine Vorstellung davon, was migriert werden soll. Ich empfehle jedoch, die Datenbanken nach Projekten abzufragen, damit keine übersehen werden.

Die Datenbanken existieren möglicherweise schon länger als die Personen, die aktuell in den Teams arbeiten. Ihr müsst die Projekte bewerten, um festzulegen, ob sie migriert werden sollen oder übersprungen werden können. Einige Projekte enthalten Unterprojekte, und ihr müsst entscheiden, wie diese migriert werden. Sie sollten entweder als Submodule erhalten bleiben oder als Unterverzeichnis angelegt werden.

Auswirkungen von Dateirevisionen

Die Arbeit mit einem Client-Server-SCM hat häufig dazu geführt, dass Artefakte, Abhängigkeiten und Tools im Quellcode gespeichert werden. Das passt nicht gut zu einem verteilten Versionskontrollsystem wie Git, da ihr standardmäßig die gesamte Historie der Commits und Dateien mitführt.

Die Größe des Repositorys selbst, aber auch der Größenzuwachs pro Revision, geben einen ersten Hinweis darauf, ob das Repository langfristig tragfähig ist. Mögliche Maßnahmen reichen vom Entfernen von Dateien über die Aufnahme in einen Artefaktmanager bis hin zum Einsatz von Git Large Files System (LFS) oder Submodulen. Welche Lösung für welche Datei oder welchen Bereich am besten geeignet ist, lässt sich im Voraus nur schwer sagen. Diese Bewertung und die Maßnahmen sollten innerhalb der Organisation entschieden werden.

Metadaten – Dateien, Tasks und Baselines

Wie oben erwähnt, können Dateien, Tasks und Baselines nicht unverändert nach Git migriert werden, enthalten jedoch viele relevante Informationen. Das Baseline-Objekt enthält diese Informationen und kann zusammen mit der Commit-Nachricht einem annotierten Tag hinzugefügt werden. Das ist hilfreich, da diese Informationen über Git durchsuchbar und auch von Git-Repository-Managern auswertbar sind. So entsteht eine Brücke für die Traceability zwischen Synergy und Git. Synergy-Tasks und Rational-Change-Probleme könnt ihr in euer Task-Management-Tool migrieren. Die Tasks können Informationen über den Bearbeiter, das Release, eine Beschreibung und Dateilisten enthalten.

Repository-Manager und Task-Management-Systeme verfügen in der Regel über Integrationen, sodass ihr in Commit-Nachrichten auf Tasks verweisen könnt. Mit dieser Methode lassen sich die migrierten Projektrevisionen mit den Tasks im Task-Management-System verknüpfen. Das sorgt für eine umfassende Traceability der historischen Revisionen. Ich habe bereits eine Migration zu BitBucket und Jira durchgeführt. Synergy-Tasks wurden dabei zusammen mit FixVersions und Komponenten als Stories nach Jira migriert.

Iterationen und Verifizierung

Meine Erfahrung der vergangenen Jahre zeigt, dass ihr die Migrationswerkzeuge mehrmals anpassen müsst, um alles richtig umzusetzen. Es ist ein iterativer Prozess. Dabei müssen Entscheidungen zu Prozessen und Strukturen getroffen werden. Höchstwahrscheinlich wechselt ihr den Motor, während das Auto fährt – daher solltet ihr damit rechnen, die Migration mehrmals zu üben.

Die Migration sollte sowohl technisch als auch aus Prozesssicht verifiziert werden.

Technisch könnt ihr die Dateien und Strukturen einer aus Synergy exportierten Revision mit denen eines aus Git abgerufenen Tags vergleichen. Können wir die Software bauen und verifizieren? Könnt ihr Dokumentation generieren sowie Artefakte und Releases erstellen?

Aus Prozesssicht müsst ihr einen vollständigen Entwicklungs- und Delivery-Lifecycle in Git durchlaufen, um sicherzustellen, dass ihr auf Basis von Git arbeiten könnt.

Durchführung der Migration

In den vorherigen Abschnitten habe ich Herausforderungen und mögliche Lösungen beschrieben, die sich aus den unterschiedlichen Datenmodellen ergeben. Viele dieser Elemente sind in unserem Open-Source-Tool 2git implementiert, das für ClearCase- und Synergy-Migrationen eingesetzt wurde.

Die Migration besteht aus zwei wesentlichen Teilen. Im ersten Teil wird der Quellcode ohne Änderungen und Optimierungen aus Synergy nach Git übertragen. Im zweiten Teil wird das Git-Repository optimiert und um die Abhängigkeiten ergänzt.

Synergy zu Git:

1. Führt 2git mit dem ccm2git-Driver aus. Das Ergebnis ist eine nicht optimierte Git-Historie ohne Submodule.

2. Datei- und Strukturvergleich zwischen derselben Revision aus Synergy und Git

3. Software aus Git bauen

4. Ergebnis bewerten

5. Repository analysieren, um Dateien zu identifizieren, die entfernt werden sollen, sowie die LFS-Konfiguration für Phase 2 festzulegen. Eine Möglichkeit wäre, den git-repo-analyser zu verwenden, um die Dateien mit den größten Auswirkungen auf das Git-Repository zu finden.

Wiederholt diese Schritte, bis ihr mit der Migration zufrieden seid.

Git-Optimierung:

1. .gitignore und .gitattributes anhand der Repository-Analyse aus Phase 1 aktualisieren

2. Abhängigkeiten zu einem Artifact-Management-System hinzufügen

3. 2git mit dem git2git-with-ccm-flavour ausführen. Das Ergebnis ist eine Git-Historie, die mit Submodulen optimiert ist.

4. Datei- und Strukturvergleich zwischen derselben Revision aus Synergy und Git

5. Abhängigkeiten und Tools hinzufügen, die in Git nicht vorhanden sind

6. Basierend auf euren Entscheidungen das 2git-Tool aktualisieren, um Abhängigkeiten und Tools zu übernehmen

7. Software aus Git bauen

8. Ergebnis bewerten

Die oben genannten Schritte wiederholen, bis ihr zufrieden seid

Livegang

Delta- und Teilmigrationen

Für größere Unternehmen kann es schwierig sein, Teammitglieder in Git und neuen Prozessen zu schulen. In diesem Fall können Teilmigrationen sinnvoll sein. Diese können entweder auf Projektebene erfolgen oder auf Synergy-Releases basieren.

2git kann Delta-Migrationen durchführen und nur die fehlenden Projektrevisionen nach Git migrieren. Das macht den Prozess flexibel und reduziert den Umfang eines „Big Bang“. Ich empfehle, mit Projekten auf oberster Ebene zu beginnen. Erstens, weil keine anderen Synergy-Projekte von diesen Projekten abhängen, und zweitens, weil ihr frühzeitig überprüfen könnt, ob sich Produkt-Releases mit dem neuen Tool-Stack erstellen lassen. Das senkt das Risiko in den Softwareprojekten. Die Subsysteme können weiterhin in Synergy Releases erstellen, und der Git-Tag bzw. Commit wird nach einem weiteren Durchlauf von 2git für die Integration verfügbar.

Branching-Strategie definieren

Wie bereits erwähnt, unterscheiden sich Synergy und Git hinsichtlich Releases und Branches. In beiden Setups liefert ein Entwickler Änderungen jeweils an ein Release oder einen Branch. In Synergy gibt es jedoch keinen Default-Branch und kein Konzept für trunk-based Development. Vielleicht habt ihr dies in Synergy bereits selbst umgesetzt, was großartig ist. Dann könnt ihr die Git-Arbeitsweise sofort nutzen, indem ihr denselben Branch als Default-Branch festlegt.

Es gibt viele Ansätze für das Git-Branch-Management. Ohne fundierte Kenntnisse eurer aktuellen Arbeitsweise und Rahmenbedingungen ist es schwer, einen bestimmten Ansatz zu empfehlen.

Ich empfehle, die migrierte Historie in Git zu untersuchen, um gut zu verstehen, wie sich eure Software-Assets im Laufe der Zeit entwickelt haben. Ihr könnt sehr anschaulich sehen, wie sich die Projektrevisionen und ihre Baselines entwickelt haben und wo es Verzweigungen in der Historie gibt.

Jede Verzweigung weist auf einen Branch hin. Relevant sind jedoch nur die potenziell aktiven Branches, die in naher Zukunft Commits erhalten werden. Bei Bedarf könnt ihr jederzeit weitere erstellen.

Nachbereitung

Ihr habt jetzt zu Git migriert und profitiert von den Vorteilen, doch Gewohnheiten zu ändern, kann schwierig sein.

Viele Unternehmen entwickeln beispielsweise weiterhin auf Release-Branches. Mit Git könnt ihr Features jedoch stattdessen auf dem Master-Branch entwickeln und Release-Branches nur dann erstellen, wenn sie für die Reifung benötigt werden. Ihr müsst aktiv daran arbeiten, von frühem zu spätem Branching überzugehen, um von einer weniger auseinanderlaufenden Codebasis zu profitieren.

Merges sind in Synergy aufwendig. Deshalb führt ihr Release-Branches nur selten wieder mit der Mainline zusammen. Möglicherweise werden die Änderungen gar nicht gemergt: Stattdessen werden Entwickler gebeten, dieselben Änderungen auf mehreren Branches erneut zu implementieren.

Ihr könnt jetzt eine Branching-Strategie entwickeln, die dies automatisiert ermöglicht. Git führt Merges schnell und zuverlässig aus. Sie lassen sich sogar in eure Continuous-Integration-Plattform integrieren. Ich bevorzuge Git Phlow, da es so konzipiert ist, dass ihr Änderungen nur einmal implementiert und die Automatisierung sie über einfache Merges in die Mainline übernimmt.

Fazit

Eine Synergy-Migration wirkt aufgrund ihres Umfangs und der darum herum aufgebauten Legacy-Tools meist abschreckend, ist mit dem richtigen Wissen und den passenden Fähigkeiten jedoch gut machbar. Erfahrung hilft ebenfalls. Wir haben große, global tätige Unternehmen dabei unterstützt.

Mit unserem Eficode ROOT Managed Service können wir auch euer GitLab für euch verwalten.