Das Konnektor-Monorepo: Git für Fortgeschrittene

Die Entwicklung des Konnektors beschäftigt unser Unternehmen schon seit längerer Zeit. In solchen lang laufenden Projekten ist es notwendig, Annahmen zu überprüfen und Vorgehensweisen zu hinterfragen. Passiert das nicht regelmäßig, kann es sein, dass sich das Projekt in eine technologische oder organisatorische Sackgasse bewegt.

Wir waren in einer solchen Situation mit Hinblick auf unser Versionsverwaltungssystem. Zwar sind wir schon vor einiger Zeit erfolgreich von Subversion auf Git umgestiegen, jedoch haben wir die Verwaltung der Software strukturell so belassen, wie wir vor einigen Jahren begonnen haben: Jedes der Subsysteme des Konnektors liegt in einem eigenen Repository. Dies war eine sinnvolle Entscheidung zum Beginn der Entwicklung, gerade in Bezug auf die damalige Struktur des Zertifizierungsverfahrens. Doch mittlerweile haben sich auch hier die Rahmenbedingungen verändert, sodass uns in den vergangenen Monaten immer schmerzlicher bewusst wurde, dass die gewählte Aufteilung mit großem Aufwand verbunden ist: Teile des Build-Prozesses sind nur dafür da, die richtigen Repositories in den richtigen Version auszuchecken. Patch-Workflows müssen auf vielen Repositories basieren, was die Fehleranfälligkeit erhöht.

Die Entscheidung, hier etwas zu ändern, war schnell getroffen. Die Quellen des Konnektors sollten in ein vereinheitlichtes Repository überführt werden. Wir nennen dieses Repository ein Monorepo. Allerdings ist dies kein einfaches Unterfangen. Die gesamte Historie aller Repositories sollte erhalten bleiben, außerdem einige Release-Branchen der letzten Zeit sowie die Tags, die Zwischenstände im Source Code markieren.

Gelungen ist uns dies schließlich mit einer Reihe von Shell-Skripten, die die Migration implementieren. Bei der Entwicklung des Verfahrens stand das Ziel eines hohen Automatisierungsgrads im Vordergrund. Da nicht klar war, wann der geeignete Zeitpunkt für die Umstellung sein würde, musste das Verfahren jederzeit wiederholbar sein, um nicht stundenlange manuelle Arbeit wegwerfen zu müssen.

Wir konnten das Verfahren bei einem zweiten Projekt anwenden. Bei genauerer Betrachtung ließen sich die Skripte mit geringem Aufwand weiterentwickeln, sodass sie komplett generisch wurden. Nach den guten Erfahrungen mit n-doc haben wir uns dafür entschieden, die Skripte unter der MIT-Lizenz auf GitHub zu veröffentlichen: https://github.com/n-design/repomerger.

Neben den eigentlichen Skripten für die Migration von einem Polyrepo in ein Monorepo liegt dort ein Skript, das eine Reihe von Beispiel-Repositories erzeugt, auf die sich das Verfahren anwenden lässt. Damit kann man sich der Migration Stück für Stück annähern und die Zusammenhänge verstehen, bevor man die Skripte für das eigene Projekt anwendet.

Wenn Sie Interesse oder Bedarf an dem Verfahren haben, melden Sie sich gerne bei uns. Wir unterstützen Sie gerne bei der Anpassung auf Ihr Projektumfeld.