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.

Git Schulung

In unserer Git Schulung lernen Admins und Opsies effizient über Git mit Kollegen und Kolleginnen zusammenzuarbeiten, Git-Repositories zu verwalten und auftretende Fehler selbst zu beheben.

Mehr erfahren