Der Weg zum SCM-Manager

Bekannte Situation? Unübersichtliche Versionsverwaltung

Eine Versionsverwaltung zu nutzen ist heutzutage zum Glück zu einer Selbstverständlichkeit für Softwareentwickler geworden. Aber auch in anderen Berufszweigen wird dieses Konzept geschätzt und genutzt, sei es der Romanautor, der jeden Abend automatisiert seinen aktuellen Stand festhält oder das Ingenieurbüro, das seine technischen Daten verwaltet. Dank Git und Mercurial ist eine Versionsverwaltung auch keine Sache mehr, die dem professionellen Einsatz mit Server vorbehalten wäre. Ein Repository ist mit einem kurzen Befehl eingerichtet und bereit, zu wachsen. Manchmal ergeben sich aber genau daraus Situationen, die nicht mehr optimal sind und an denen gerne etwas verändert werden dürfte. So ist es vielleicht das zwölfte Git Repository auf dem Samba Laufwerk, das dann nach etwas mehr Übersicht verlangt, oder die verschiedenen Systeme für Git, Mercurial und SVN, die gerne unter einen Hut gebracht werden wollen. Vielleicht steht aber auch ein Umzug aus einer eigentlich lieb gewonnenen Cloud-basierten Umgebung auf eigene Server an. Die Ziele des SCM-Manager sind seit jeher die Unterstützung von Git, Mercurial und SVN, eine Installationsanleitungen für SCM-Manager und die flexible Erweiterbarkeit, so dass es sich immer lohnt, den SCM-Manager in die Überlegungen mit einzubeziehen. Sei es der Betrieb auf dem heimischen NAS oder in der Cloud im Zusammenspiel mit Nexus, Jenkins und anderen Diensten. Um die ersten Schritte etwas zu vereinfachen, wollen wir an dieser Stelle für beispielhafte Szenarien beschreiben, wie der SCM-Manager einen Umzug unterstützen kann.

Szenario 1: Vom Netzlaufwerk zum SCM-Manager

Wenn man klein anfängt, dann beginnt es häufig mit einem einfachen Verzeichnis, das unter Versionskontrolle gestellt wird. Bei Git und Mercurial geschieht dies direkt im Arbeitsverzeichnis, bei SVN genügt ein zweiter Ordner. Eventuell wandert ein Ordner auf ein Netzlaufwerk, weil weitere Zugriffe notwendig werden. Und spätestens dann, wenn die Anforderung nach verschiedenen Berechtigungen im Raum steht, sollte über die Bereitstellung eines Servers nachgedacht werden. SCM-Manager arbeitet intern mit denselben Verzeichnisstrukturen, die auch die nativen Git, Mercurial oder SVN Clients nutzen. Dennoch sollte man der Versuchung widerstehen, die bereits vorhandenen Verzeichnisse einfach an entsprechende Stellen im Ordner für den SCM-Manager zu kopieren. Stattdessen sollte immer ein Import oder ein normaler “Push” genutzt werden. Für SVN kann ein per svnadmin erzeugter Dump direkt über die Import-Funktion im SCM-Manager eingespielt werden („Repository hinzufügen“ - „Repository importieren“). Bei Git und Mercurial kann ein leeres Repository erstellt werden, in das anschließend per ‘git push’ bzw. ‘hg push’ die gewünschten Branches eingespielt werden.

Szenario 2: Upgrade eines alten SCM-Manager

Im zweiten Szenario läuft irgendwo bereits ein alter SCM-Manager in Version 1. Im Idealfall sollte das natürlich eine 1.60 sein, aber was ist schon ideal? Und nur unter uns: Selbst in Version 1.60 ist dieser SCM-Manager End-of-Life und sollte auf den aktuellen Stand gebracht werden. Also nehmen wir zunächst einmal den einfachen Weg: Die Migration der kompletten Installation.

Komplette Migration von Version 1

Voraussetzung für die Migration zum SCM-Manager v2 von einer Installation mit Version 1.x ist, dass zumindest einmal die Version 1.60 gestartet wurde. Nur so kann sichergestellt werden, dass alle Daten im aktuellen Format vorliegen. Nach einem obligatorischen Backup (oder noch besser auf einer Testumgebung) kann nun mit dem Verzeichnis mit den Daten ein aktueller SCM-Manager gestartet werden. Dieser erkennt, dass ein Verzeichnis mit v1-Daten vorliegt und startet im Migrationsassistenten. Auf dieser Seite kann für jedes einzelne Repository gewählt werden, wie es im neuen SCM-Manager heißen soll oder ob es überhaupt übernommen werden soll. Ist dieser manuelle Schritt abgeschlossen, werden die einzelnen Repositories sowie Benutzer, Gruppen und weitere Einstellungen sowie Berechtigungen konvertiert und der SCM-Manager wird mit den bekannten Daten im neuen Gewand gestartet. Zu beachten ist, dass eventuelle vorher installierte Plugins nicht automatisch neu installiert werden. Also sollte der erste Schritt ein Besuch der Plugin-Seite sein. Hier stehen eine große Menge der aus v1 bekannten Plugins auch für v2 zur Verfügung. Die bereits aus der vorherigen Installation vorhandenen Daten für die Plugins übernehmen diese nach der Installation, so dass hier keine Daten verloren gehen sollten.

Import aus einer v1 Instanz

Da es den SCM-Manager bereits seit über 10 Jahren gibt, kann es durchaus vorkommen, dass eine Installation etwas an Übersichtlichkeit verloren hat und sich eine Aufteilung auf mehrere neue Instanzen anbietet. Sollen bei dieser Aufteilung tatsächlich nur die eigentlichen Repositories und keine Metadaten übernommen werden, so können auch einzelne Repositories per Import aus der alten Instanz „abgezogen“ werden. Oder aber es besteht bereits eine neue SCM-Manager v2 Instanz, in die noch einige Repositories aus einer alten Installation übernommen werden sollen. Hier kann das Script Plugin behilflich sein. Für dieses haben wir im Community Forum bereits einmal zwei Skripte veröffentlicht, mit denen ein Import mehrerer Repositories automatisiert durchgeführt werden kann.

Der Umstieg auf SCM-Manager v2

Ein Umstieg von einem System auf ein anderes will gut überlegt sein. Das gilt umso mehr, wenn es sich um ein Teil in einem größeren Umfeld handelt. Hier bietet es sich an, den SCM-Manager testweise zu installieren.

Die Testinstallation

Um ein Gefühl dafür zu bekommen, wie sich der SCM-Manager im täglichen Arbeitsumfeld schlägt, können Repositories mithilfe eines Plugins gespiegelt werden. Ein gespiegeltes Repository lädt regelmäßig alle Änderungen aus einem anderen Repository. Auf diese Weise kann der gewohnte Ablauf für unbestimmte Zeit unbeirrt weiterlaufen, während sozusagen auf einem Nebengleis die ersten Experimente mit produktiven Daten gefahrlos ausprobiert werden können.

So kann an ein gespiegeltes Repository z. B. ein Jenkins angebunden werden, der dann bei allen Änderungen im produktiven System entsprechend Builds startet. Die bestehenden Systeme werden dabei nicht geändert, so dass kein Risiko besteht und ausführlich Zeit zur Prüfung besteht. Im Übrigen ist es zudem möglich, Filter für ein gespiegeltes Repository zu setzen. So können z. B. nur bestimmte Branches übernommen oder Commits ohne Signatur zurückgewiesen werden. Die folgende Abbildung zeigt den Dialog zur Erstellung eines gespiegelten Repositories in SCM-Manager v2:

Der Umzug auf die neue Version

Ist die Entscheidung für den SCM-Manager gefallen, so können Repositories aus Fremdsystemen sehr einfach importiert werden. Wurde bereits ein Repository gespiegelt, so kann dieses in den Einstellungen des Repositories unter „Spiegelung“ mit einem Klick auf „Repository entspiegeln“ in ein „richtiges“ Repository umgewandelt werden. Ansonsten können bestehende Repositories aus Fremdsystemen auch problemlos direkt importiert werden. Bei Git werden hierbei auch LFS Dateien direkt übernommen. Es genügt, die URL und ggf. Benutzername und Passwort anzugeben, und das Repository kann direkt genutzt werden.

Stichwort Umzug: Natürlich unterstützt der SCM-Manager auch Umzüge von einem SCM-Manager in einen anderen. Repositories können exportiert werden. Ein solcher Export kann entweder nur die nativen Repository Daten (also den reinen Git, Mercurial oder SVN Teil) beinhalten oder zusätzlich auch alle Metadaten umfassen (also alle Einstellungen und sonstige Daten wie z. B. Pull Requests aus dem Review Plugin). Wird etwas mehr Sicherheit benötigt, so können die Exporte zusätzlich mit einem Passwort geschützt werden.

Bei dem Import in eine neue SCM-Manager Instanz ist nur darauf zu achten, dass diese nicht älter ist (also keine kleinere Versionsnummer hat) und auch, dass die Plugins entsprechend aktuell sind.

Fazit

Aufgrund der offenen Struktur bietet der SCM-Manager eine Vielzahl an Möglichkeiten. Diese beschränken sich nicht im Zusammenspiel mit anderen Systemen wie Jenkins, sondern zeigen sich bereits beim Im- und Export von Repositories. So kann ein SCM-Manager flexibel evaluiert, angepasst und erweitert werden. Für die Übernahme von Daten aus Fremdsystemen als auch den Umzug zwischen SCM-Manager-Instanzen stehen diverse Möglichkeiten zur Verfügung. Wir würden uns freuen, Ihre Geschichte zum SCM-Manager zu hören. Zögern Sie nicht und wenden Sie sich bei Fragen oder weiteren Wünschen an uns.