Juni 2023 – Mit Blick auf einen möglichen Migrationszeitpunkt im Oktober wurde es jetzt immer wichtiger, auch die Prozesse außerhalb des Builds an das Git-Projekt zu adaptieren. Dazu gehören Themen, wie z. B. die Übertragung von Versionen in das Ticketsystem und das regelmäßige Aufräumen von entstandenen Buildartefakten und Deployments.

Ein ganz wichtiger Punkt ist aber natürlich die automatisierte Ausführung von Oberflächen-Tests auf unseren Testumgebungen. Die Testfälle werden in dem selben Repository gepflegt und müssen daher zukünftig von den Agenten aus Git ausgecheckt werden können.

Hier ist erwähnenswert, dass wir durch die Verwendung von Shallow-Clone und einem Sparse-Checkout die Zeit auf ein Minimun reduzieren konnten, die ein Agent mit dem Checkout verbringen muss.

Der Checkout unter SVN hat noch mehrere Minuten gedauert. Mit Git sind wir durch diese Variante bei unter 10 Sekunden gelandet.

Juli / August 2023 – Immer wichtiger wurde auch, dass für die abschließende Migration vorhandene Branches berücksichtigt werden können. Das war zugleich auch eine der größten Herausforderungen. Warum wird sich gleich zeigen.

Mit git-svn ist es auch möglich Branches zu migrieren. Dazu wird bei der Initialisierung einfach ein zusätzlicher Konfigurationsparameter angegeben.

In der Konfiguration des Git-Repositories entsteht dabei folgender Block:

Bei kleinen Repositories und einer einheitlichen Struktur liefert dieses Vorgehen zuverlässig und in überschaubarer Zeit ein identisches Abbild in Git.

Unser SVN-Repository betrug 4.181.119 Revisionen und folgte nicht ganz der Standardstruktur. Die Branches lagen bei uns nicht direkt unter branches, sondern wurden nach Meilenstein in Unterordnern gruppiert. Noch dazu hatte sich die Struktur mehrmals geändert und Branches wurden teils kaskadierend von anderen Branches eröffnet. Das hat uns die Konfiguration für Git erschwert und auch zu einer höheren Laufzeit geführt. Um die SVN-Historie vollständig nachzuvollziehen durchlief Git bei uns in Testszenarien teilweise mehrmals die gesamte Historie und hat in jeder Revision nach passenden Pfaden gesucht. Bei 4 Millionen Revision und mehreren hundert Branches wird das schnell kostspielig. Erfahrungsgemäß sitzt so eine Konfiguration auch nicht sofort und man muss nach Anpassungen die Migration nochmals laufen lassen. In der Hoffnung, dass dann alles stimmt. Das war also nicht der richtige Weg für uns.

Stattdessen haben wir nach Alternativen gesucht. Zum Ziel haben wir uns dabei gesetzt, alle Branches zu migrieren, zu denen die Software in der Vergangenheit beim Kunden produktiv im Einsatz war. Die konnten wir gut identifizieren. Die Branches sollten inhaltlich migriert werden, ein 1:1 Abbild des Repositories inklusive korrektem Merge-Graphen war aber nachrangig.

Da die Migration per git-svn grundsätzlich gut funktionierte, haben wir versucht die Analyse des SVN-Repos vorweg zu übernehmen. Die Idee war, dass wir ein Migrationsskript vorbereiten, welches die konkreten Revisionen zu den gewünschten Pfaden kennt und so Stück für Stück migriert. Git muss dann nicht selber suchen, sondern bekommt von uns gesagt, was es woher zu nehmen hat.

In git-svn ist es möglich auch mehrere SVN-Remotes zu konfigurieren. Darüber haben wir die gewünschten Branches getrennt voneinander abgebildet.

Beim Aufruf von git-svn kann ich auch bestimmen, welche Konfiguration genutzt werden soll. In Kombination mit der Angabe von Revisionsranges konnten wir unser Repository Schritt für Schritt migrieren und git-svn von vornherein mitteilen, welchen Branch es in welchem Revisionsbereich findet.

Zur Erstellung von Konfiguration und Skript haben wir uns ein kleines Java-Tool geschrieben. Das hat alle SVN-Revisionen nach unseren gewünschten Branches durchsucht und beide Dateien geschrieben. Wir haben dafür die Bibliothek SVNKit verwendet. Innerhalb von 20 Minuten konnten wir damit eine neue Konfiguration erstellen und Anpassungen fielen somit deutlich leichter.

Wichtig ist an dieser Stelle, dass in dem entstandenen Git-Repository die gesamte Historie zusammenhängend ist. Das kann geprüft werden, in dem wir alle Branches auflisten, die den allerersten Commit nicht beinhalten.

Die Ausgabe sollte im Idealfall leer sein. Wenn trotzdem Branches aufgelistet werden, bedeutet das, dass bei der Migration Lücken existieren und git-svn den Zusammenhang zur restlichen Historie für diese Branches deshalb nicht feststellen konnte.

Die Migration selbst dauerte mit diesem Skript dann ca. zwei Tage. Das entstandene Git Repository war jetzt über 60 GB groß. Dank der Filterung sind wir aber auch hier wieder auf ca. 2,4 GB gekommen. Dieses neue Repository hat das bisherige abgelöst und war der endgültige Stand mit dem wir später auch Live gegangen.

September 2023 – Ein Monat vor dem Umstieg. Die zum Start wichtigsten Prozesse standen. Wir haben uns um die vorerst letzten Themen gekümmert.

In Anlehnung an die Migration der historischen Branches haben wir einen Prozess erarbeitet, wie wir gegebenenfalls noch offene SVN Feature-Branches nachträglich nach Git migrieren können.

Außerdem haben wir das genaue Vorgehen für den Umstieg näher betrachtet und für die Belegschaft dokumentiert und grafisch aufbereitet. Wir sind nämlich nicht vollständig in einem Schritt zu Git gewechselt, sondern haben mit dem Beginn der Entwicklungsphase für einen neuen Meilenstein den Umstieg auf Git begonnen. Das vorige Release wurde weiter in SVN geführt, der Stand aber natürlich auch laufend nach Git übertragen. Das wird in Frank’s Beitrag noch näher beleuchtet.

Zusätzlich haben wir zwei Schulungstermine vorbereitet, um den anderen Teams zum Umstieg einen möglichst sanften Einstieg zu ermöglichen. Darin sind wir zusätzlich auf die konkrete Strategie für die Übergangsphase eingegangen und haben diese erläutert. Die Schulungen waren in zwei unterschiedliche Level geteilt. Die erste richtete sich eher an fortgeschrittene Nutzer und basierte viel auf dem Kommandozeilenclient. In der zweiten haben wir mehr grafische Oberflächen gezeigt.

09. Oktober 2023 – In der vorigen Woche haben wir die Schulungen gehalten. Am Wochenende wurde das vorletzte Release aus SVN produktiv gesetzt. Ab jetzt startet die erste Entwicklung in Git. Und nun? Nichts… irgendwie lief einfach alles weiter.

Na gut, aus den Entwicklungsteams kamen in der ersten Zeit noch einige Rückfragen zu der Arbeit mit Git. Dafür haben wir während der Übergangsphase eine tägliche Austauschrunde für alle angeboten. Wer ein Anliegen, Fragen oder allgemein Bedarf zum Austausch rund um das Thema Git hatte, war herzlich eingeladen. Das wurde mit der Zeit aber immer weniger genutzt.

Außerdem hatten wir kleine Nacharbeiten. So musste z. B. der Prozess zur Erstellung eines Changelogs noch für Git realisiert werden. Auch in unserem Versionierungs-Plugin sind im produktiven Betrieb dann noch ein paar Konstellationen hochgekommen, in denen es nicht korrekt die Version hochgezählt hat. Das waren aber alles kleinere Probleme, die wir gut lösen konnten.

In den folgenden Monaten haben wir noch die letzten relevanten Tools in Git-Repositories überführt. Technische Schulden, wie z. B. SVN-relevanten Code konnten wir endlich entfernen. Ein gutes Gefühl.

Inzwischen sind wir im April 2024. Wir arbeiten jetzt ausschließlich unter Git und ich schreibe rückblickend diesen Artikel. Im Vordergrund sollte unser grundsätzliches Vorgehen stehen, nichtsdestotrotz wollte ich auch ein bisschen Code zeigen. Ich hoffe Euch damit einen guten Einblick gegeben zu haben. Eventuell habt Ihr ja ein ähnliches Projekt vor Euch. Wenn Ihr auch von SVN kommt, könnt Ihr sogar die gleichen Tools ausprobieren. Wenn nicht, kann Euch vielleicht immerhin der ein oder andere Ansatz als Inspiration dienen und muss nur auf andere Tools übertragen werden.

In jedem Fall steht euch ein spannender Weg bevor, ich wünsche euch viel Erfolg!

Über den Autor:

Hi, ich bin Helge! Ursprünglich in Hamburg geboren, wohne ich seit 2019 mit meiner Familie in Wedel.

Bei intersoft bin ich seit über 15 Jahren an der Bereitstellung und Gestaltung von Infrastruktur und Prozessen rund um Build und Deployment unserer Software-Produkte beteiligt. Der Markt hat sich in dieser Zeit stark weiterentwickelt, sodass ich das heute als DevOps-Engineer in einem Kubernetes-Umfeld tue.

Auch privat interessiere ich mich für neue Technologien und probiere gern in kleinen Projekten das eine oder andere aus.