Boehrsi.de - IT und Gaming Blog

Um sowohl ein hohes Maß an Wiederverwendbarkeit, wie auch ein niedriges Level an Komplexität zu erreichen, habe ich mir für meine Boehrsi.de Services eine Kleinigkeit überlegt. Meinen Ansatz zur flexiblen Entwicklung ohne unnötigen Overhead möchte ich im Folgenden mit euch teilen. Dabei geht es um die Datei- und Git-Struktur, denn auf den Code Aufbau werde ich in einem gesonderten Beitrag eingehen.
Wie bereits erwähnt gibt es viele Wege und das Spektrum ist sehr breit, wenn es darum geht ein Setup für Projekte mit mehreren Modulen, bzw. einem gewissen Level an Flexibilität zu erreichen. Um einordnen zu können wo mein Konzept hilfreich sein könnte und wo es an seine Grenzen stößt, gibt es im folgenden meine Anforderungen und die Beschreibung meines eigentlichen Ziels.

• Eine zentrale Codebasis stellt Grundfunktionen zur Verfügung. Diese Codebasis soll in verschiedene Services schnell und einfach nutzbar sein
• Die Codebasis soll gut und unabhängig von den eigentlichen Services / Implementierung wartbar sein
• Alle allgemein nutzbaren Features oder Utilities werden in die zentrale Codebasis ausgelagert
• Eine Implementierung erfüllt eine konkrete Aufgabe
• Eine Implementierung greift auf die eigenen und die durch die zentrale Codebasis bereitgestellten Funktionen zu. Generell sollten Implementierungen nicht mit anderen Implementierungen interagieren
• Die Kombination aus der zentralen Codebasis und 1 bis n Implementierungen ergibt einen Service
• Es soll kein komplexes Tooling auf dem Server oder dem Entwicklersystem nötig sein
• Wenig bis kein Scripting soll während der Entwicklung nötig sein, dafür sind kleinere manuelle Arbeitsschritte in Ordnung

Mit diesen Grundideen habe ich verschiedene Ansätze, alle in Verbindung mit Git open_in_new, durchdacht und mir folgendes ausgedacht.

• Ein Repository hält die Codebasis bzw. den Core
• Alle Services arbeiten auf dem selben Core Repository, können aber unterschiedliche Versionen nutzen
• Jede Implementierung liegt in einem eigenen Repository
• Alle Services arbeiten auf den selben Repositories der Implementierungen, können aber unterschiedliche Versionen nutzen

open_in_new

Bei der lokalen Entwicklung ergibt sich dabei folgendes.

• Für einen neuen Service wird das Core Repository ausgecheckt
• In einem Unterordner, welcher auf Git Ebene vom Core Repository ignoriert wird, werden 1 bis n Implementierungen ausgecheckt
• Eine Mapping-Datei, welche ebenfalls auf Git Ebene vom Core Repository ignoriert wird, sorgt dann für die eigentliche Verbindung auf Codeebene
• Änderungen am Code werden im jeweiligen Repository eingebunden, ohne das die anderen Repositories geändert werden müssen

open_in_new

Auf diese Weise kann sowohl der Core, wie auch eine beliebige Implementierung, in verschiedenen Diensten unabhängig voneinander wiederverwendet werden. Der jeweilige Code wird zentral gepflegt und verschiedene Services können bei Bedarf auf etwaige Aktualisierungen zugreifen. Sofern ein Service Änderungen noch nicht nutzen soll, wird das jeweilige Repository einfach nicht aktualisiert. In Ausnahmefällen kann man permanente Unterschiede durch verschiedene Branches lösen, dies sollte im Normalfall aber nicht nötig sein. Aufgrund von diversen schlechten Erfahrungen nutze ich keine Git Submodules.
Die Erwähnte Mapping-Datei wird lokal gepflegt, da sie in keinem Repository zu finden ist. Aufgrund ihres trivialen Aufbaus stellt dies kein Problem da. In diesem Bereich ist es außerdem noch möglich mit Skripten oder anderen Lösungen Dinge weiter zu automatisieren, doch aktuell sehe ich persönlich hier keinen Bedarf. Solltet ihr Interesse an einer weiterführenden Automatisierung haben, werde ich gerne eine weiteren Beitrag zu diesem Thema verfassen.

Zusammengefasst kann man sagen, dass der genannte Aufbau einen modularen Serviceaufbau während der Entwicklung erlaubt und das ohne komplexe Git Strukturen oder andere komplizierte Lösungen. Dafür ist die Verbindung nur lose und sofern größere Teams an einem komplexen Projekt arbeiten, wird der Ansatz nur schlecht skalieren. Grund dafür ist vor allem, dass die eigentlich Verbindung nur lokal beim jeweiligen Entwickler stattfindet und nicht zentral verwaltet wird. Entsprechend ist der Ansatz für weniger komplexe Projekte oder Projekte mit kleinerer Teamgröße ideal. Es sollte allerdings möglich sein, mit relativen geringem Skirpt-Aufwand, hier etwas Abhilfe zu schaffen.

Für mich persönlich funktioniert das Setup bis dato sehr gut. Es wird produktiv hier im Blog für die Suche und die Kommentare eingesetzt. Beide Features sind jeweils eine Implementierung, welche durch den Core zusammengehalten werden. Zusammen ergibt das Ganze einen Service, welcher als eine Instanz (ein Webserver in einer JVM) auf meinem Server läuft.