Git zieht um
Will man bei einem Umgebungswechsel auch die Git-Repositories (Repos) umziehen, gibt es Herausforderungen und Fragen, die im Voraus geklärt werden sollen. Wir haben schon so ziemlich alles erlebt, was bei so einer Migration passieren kann, und teilen hier unsere Erfahrungen.
Die Situation
Warum auch immer, Menschen in der IT entscheiden sich ab und zu mal dafür, ihre vollkommen perfekt funktionierenden Softwareumgebungen umzuziehen. Auch, wenn diese Idee dem wichtigsten Grundprinzip des Betriebs stark entgegenspricht: „If it works, don’t touch!“ heißt es, und es lohnt sich wirklich, sich dieses Motto zu Herzen zu nehmen.
Es kann natürlich Gründe geben, warum man diesen Schritt gehen will: Man möchte zum Beispiel eine eigene Umgebung aufbauen oder den Anbieter wechseln, da die neue Lösung einfach besser ist. Wenn es sein soll, dann soll es eben sein.
Und natürlich ist heute überall ein Versionsverwaltungssystem vielleicht der wichtigste Bestandsteil aller Umgebungen. Single Source of Truth, wie man so oft sagt. Hier werden alle Änderungen des Systems nachvollziehbar gespeichert. So kann man mit einem gut gestalteten System wichtigen und vernünftigen Regeln folgen, in unterschiedlichen Branches kann man gut auf unterschiedliche Bedürfnisse eingehen … Git ist eindeutig wichtig, wie Sie sehen.
Und ja, das Ding ist quasi zum Standard geworden, und deshalb wird jetzt im Weiteren über Git gesprochen. Der Autor hat noch Subversion im Einsatz gesehen, er erinnert sich aber auch noch an Zeiten, als Robbie Williams Mitglied einer Teenage-Boyband war.
Die Aufgabe
Also, bei so einem Umgebungswechsel muss Git auch mitwandern. Die ganze Struktur wird einfach migriert, und nach einem schnellen Konfigurationsupdate kann schon alles wie gewohnt weiterlaufen: Entwickler können ihre Anwendungen weiterentwickeln, Operatoren können ihre Konfigurationen pflegen, Kollege Jenkins kann alle ihm zugewiesenen Aufgaben automatisiert erledigen. Klar, einfache Aufgabe. Oder?
It’s a Trap
Wie Sie schon vermuten können, die Antwort heißt bestens jein, aber möglicher ist es, dass daraus eher ein „NEIN!!!“ wird. Bei einem unserer Kunden haben wir die Aufgabe ziemlich sauber gelöst, aber der Weg dahin war selbstverständlich gar nicht so leicht.
Was?
Eine erste wichtige Frage war, was überhaupt umgezogen werden musste. Hat man in einem System mehr als 100 Repos, ist es möglich, dass einige schon etwas veraltet sind. Man braucht sie nicht einmal mehr, da sie historisch gewachsen sind und inzwischen vergessen wurden. Eine weitere Frage ist, was genau von diesen Repos inhaltlich mitgenommen werden soll: der letzte Stand der von Git gespeicherten Änderungen des Codes oder alle Versionen? Das könnte für Historiker durchaus interessant sein. Oder für Auditoren, sollte es sich um wichtige Systeme handeln.
Wohin?
Interessante Frage, oder? Wohin sollen überhaupt die Dateien? Na, ins neue Git, fertig. Oder?
Oder eher nicht. Es kann passieren, dass der Umzug auch die Möglichkeit bietet, die etwas veraltete Logik zu ändern und eine neue Projekt- und Repo-Struktur anzulegen.
Muss so eine Strukturreform jetzt unbedingt bei einem Umzug stattfinden? In diesem konkreten Fall war es eben so. Die neue Umgebung sollte auch eine neue Struktur mitbringen. Und wir haben die Aufgabe gelöst, alles ist dort gelandet, wo es in der neuen Logik hingehörte.
Wie?
Es wäre äußerst simpel gewesen, die Repos einfach über die ins neue System eingebauten Lösungen zu importieren. Vermutlich sind Sie nicht überrascht, dass das Ganze so nicht funktioniert hat: „Wir haben die Adresse reinkopiert und auf *Weiter* geklickt“ wäre keinen Artikel Wert.
Dementsprechend haben wir eine allgemeine Lösung entworfen, die alle Anforderungen erfüllt hat.
Nach dem Anlegen der neuen Struktur, Klären der einzelnen Bestandteile, Einholen der erforderlichen Berechtigungen, Entscheiden, ob die neu angelegten Repos nur den letzten Stand des Haupt-Branches oder auch alle existierenden Branches samt Historie enthalten sollen, nach einer Absprache mit den zuständigen Kollegen, ob bestimmte Mechanismen, die fürs Validieren der einzelnen Commit-Nachrichten eingerichtet sind, kurz ausgeschaltet werden können (und ob referenzierte Ticketnummern in der neuen Struktur wieder vergeben werden dürfen), lief alles dank unserer Lösung schnell und sauber.
Und kann in ähnlichen Fällen auch erfolgreich wiederholt werden.
Fazit
Ein Git-Repo zu migrieren ist alles, außer unmöglich. Eine Versionsverwaltungsstruktur mit allen Details in einer neuen Umgebung zu implementieren ist aber etwas völlig anderes. Sind Sie auf der Suche nach einer Lösung für den zweiten Fall? Wir teilen unsere Erfahrungen gerne mit Ihnen. Wie auch hier klar sein dürfte: Um etwas Vernünftiges zu schaffen, muss man vieles im Voraus bedenken. Und da wissen wir, welche Faktoren das gewünschte Ergebnis beeinträchtigen können.
Gergely Szalay
Neueste Artikel von Gergely Szalay (alle ansehen)
- New Adventures in ArgoCD: Automatisieren des Automatisierens - 13. Juni 2023
- Git zieht um - 20. Dezember 2022
- Kubeflow at Home: KI und Kubernetes außerhalb von Google & Co - 25. Januar 2022
