Wie integriert ihr mehrere Projekte, die zwar unterschiedlich gelagert, aber miteinander verwandt sind – oder bevorzugt ihr es, sie gerade nicht zu integrieren?
Zum Beispiel, wenn es für denselben Service front-end, back-end (API), serverless, batch, pipeline usw. gibt:
-
Mono-Repo
Wenn es derselbe Service ist, dann gibt es nur ein Repository! Die einzelnen Projekte werden in einer Paket-/Ordnerstruktur organisiert.
-> Aber wie verwaltet man dann die Commits..? CI/CD oder Hooks wiepre-commitwerden dadurch doch komplizierter.. -
Git-Submodules
Wenn der Charakter unterschiedlich ist, sollte man zumindest die Git-Historie getrennt verwalten! Aber trotzdem möglichst in einem Ganzen bündeln..
-> Themen wie Submodule-Sync haben eine gewisse Lernkurve.. Merges werden auch komplexer.. Werden andere Entwickler da mitkommen? -
Eigenständige Repos
Ganz simpel! Unterschiedliche Projekte, unterschiedliche Repos!
-> Wenn ich mir Service A ansehen will, welches Repo muss ich mir anschauen? Ach, dieses hier und das da,.. was gab es noch gleich...?
Es scheint keine richtige Antwort zu geben, aber mich würde interessieren, was ihr bevorzugt – und warum!
16 Kommentare
Ich bevorzuge ein Repo, in dem jeder für sich selbst sorgt ...
Wenn bei mir die Frage aufkommt: Was muss ich mir anschauen, wenn ich die Historie der API zu dieser Funktion sehen will?, dann finde ich es praktischer, ein Repo jeweils einer einzelnen Funktion zuzuordnen.
Ich nutze in den meisten Situationen ein Monorepo, aber es gibt zwei Fälle, in denen ich Submodule verwende.
Wenn ich einen externen Publisher beauftragt habe.
Wenn ich einem externen Publisher nichts außer den für das Publishing nötigen Informationen offenlegen möchte, nutze ich Submodule.
Wenn ich eine externe Lösung anpassen muss.
Vor allem bei Lösungen, die Plugin-Funktionen bereitstellen, verwende ich Submodule.
Ich registriere die betreffende externe Lösung als Submodul und arbeite dann so, dass ich meine Plugins per Symlink o. Ä. in den Plugin-Pfad einbinde. Meine Plugins versioniere ich separat auf meine Weise, während die externe Lösung ihre eigene Versionskontrolle unverändert beibehalten kann.
Die Erfahrungen mit Submodules scheinen bei allen schlecht zu sein … Es wäre schön, wenn es ein Tool gäbe, mit dem man das verbessern könnte.
Wenn du dir zutraust, nur Merge-Commits zu machen, dann Monorepo,
wenn du ständig rebased, dann Multi-Repo,
Submodule? Nimm einfach die vom OS bereitgestellten Verzeichnis-Links …
Früher habe ich einfach jeweils eigenständige Repos verwendet, aber in letzter Zeit bin ich komplett auf die Nutzung von Submodulen umgestiegen.
Damals war mein Verständnis von Git noch gering, sodass ich Submodule nicht richtig nutzen konnte, aber inzwischen denke ich, dass die Verwendung von Submodulen die bessere Wahl ist.
Allerdings muss man bei der Nutzung von Submodulen Commits im jeweiligen Submodul machen und danach auch im Parent-Repo erneut committen. Dadurch entsteht ein zeitlicher Versatz zwischen den beiden, was wohl das Problem mit sich bringt, dass die Konsistenz des Repos leidet.
https://monorepo.tools/
Falls Sie die Website noch nicht gesehen haben, lohnt es sich, einmal hineinzuschauen.
Submodule würde ich aus persönlicher Erfahrung nicht empfehlen.
Wenn Sie Code aus einem anderen Repository per Submodule teilen möchten, ist es vermutlich besser, ihn stattdessen als Paket zu veröffentlichen.
In unserem Unternehmen sind die Teams pro Projekt klein, und da sich Sprachen und Tech-Stacks von Frontend und Backend unterscheiden, gab es kaum bereichsübergreifende Beiträge zwischen den Rollen. Wie bei allen IT-Systemen scheint es letztlich der Organisationsstruktur zu folgen.
Oh … das ist also ein Ansatz, die Sichtbarkeit des fremden Codes danach zu steuern, ob Menschen die Schnittstelle anpassen oder ob das Tool das übernimmt.
Ich habe keine Erfahrung mit Monorepos und daher eine Frage. Wenn man ein Monorepo verwendet, kommen dann gemeinsame Module für mehrere Projekte oder Services, z. B. ein Designsystem, jeweils mit in dieses Monorepo? Oder lässt man so etwas zwangsläufig in einem separaten Repository und bindet es von dort aus ein?
Beim Zugriff auf gemeinsame Module haben wir, unterstützt durch etwas wie
yarn workspace, wohl in Form von Symlinks darauf zugegriffen!Ich verwalte sowohl in der Firma als auch bei privaten Projekten Frontend, Backend, Batch-Jobs usw. nicht getrennt, sondern alles in einem einzigen Git-Repository.
Manchmal ist es auch praktischer, beide zusammen zu ändern, statt auf Abwärtskompatibilität zu pochen. Außerdem sind beide Teams eher klein, daher hätte eine künstliche Trennung aus meiner Sicht keinen großen Vorteil ... Den zusätzlichen Aufwand, GitHub Actions so einzurichten, dass nur geänderte Bereiche laufen, fand ich durchaus vertretbar. Vor allem gefällt mir mehr als die Trennung zwischen Backend und Frontend, dass beide Seiten gegenseitig beitragen können. (Wenn man zum Beispiel am Frontend arbeitet und etwas im Backend braucht, kann man es direkt selbst ergänzen oder Fehler auch selbst beheben usw. ...)
Hm, offenbar bevorzugt man eher ein Monorepo, wenn der Umfang klein ist oder die Rollen nicht streng getrennt sind! Macht es euch auch nicht viel aus, dass sich die Git-Historie vermischt? (Ist ja ohnehin Code, den sowieso alle sehen, oder?)
Das Interessante ist, dass es auch bei meinem Side Project so läuft. Bisher habe ich mit etwa 12 Leuten zusammengearbeitet. Dabei arbeitet jede einzelne Person in einem Zug vom Frontend bis zum Backend. Das ist wohl auch so etwas Ähnliches wie ein Vertical Slice.
Ich sehe das eher nicht als Vermischung. In vielen Fällen werden in einem einzigen PR sowohl Frontend als auch Backend geändert. Bei uns ist die Grundhaltung, dass wir vier Full-Stack-Entwickler sind, daher reviewen wir unabhängig von Backend oder Frontend gegenseitig und müssen auch über die Änderungen der anderen Bescheid wissen.
Wenn die Module nicht besonders groß sind, dann ein Monorepo.
Wenn die Module groß sind, dann Submodule.
Oder wenn man bei der Open-Source-Veröffentlichung nur Beiträge zu den Submodulen zulassen und das Haupt-Repo intern selbst verwalten möchte,
dann scheint eine Aufteilung in Submodule sinnvoll zu sein.
Allerdings habe ich den Eindruck, dass Submodule bei Open Source für andere Nutzer das Verfassen von Dokumentation rund um Tests oder Builds zum Beitragen etwas komplizierter machen.
Deshalb würde ich persönlich, sofern sich die Beiträge an beiden nicht unterscheiden, eher ein Monorepo wählen
oder verschiedene GitHub-Repositories verwenden und diese jeweils als Pakete oder Docker-Images veröffentlichen und so verwalten.
An Open Source hatte ich dabei gar nicht gedacht, danke für den Hinweis!