Moin,
In unserer Besprechung heute haben wir festgestellt, dass die aktuelle
technische Struktur der xRes-Software (Verzeichnis- und Repo-Struktur)
nicht optimal sind und haben Ansätze für die Lösung besprochen.
Probleme:
* Das Verzeichnis "lib" ist ein Müllhaufen ohne hinreichende Struktur
& Dokumentation und wächst weiter (in Folge der gewünschten
Zentralisierung von Funktionen). Es ist nicht hinreichend klar,
welcher Code wo im xRes verwendet wird ... oder tatsächlich nicht mehr.
=> Die Struktur, xRes in "Module" und ein gemeinsames
"lib"-Verzeichnis zu trennen, ist nicht flexibel genug. Es ist
angemessen, über eine neue und besser dokumentierbare Struktur xRes
so zu zerlegen, dass weniger "Müll" entsteht.
* Die Konfigurationen (xResConf.xml, configV2, ...) liegen in jedem
Modul-Verzeichnis (statt einmal zentral) und wird zum Teil über
diesen ÜBLEN Broadcast-Mechanismus verteilt.
* Uns ist erneut klar geworden, dass wir nicht wissen, wie ein "leeres
xRes" aussieht. Besonder das über alle Kunden einheitliche DB-Schema
und die darin zwingend erforderlichen Daten (z.B. ein erster
xAdmin-User) sollten für einen nächsten xRes-Kunden ausgearbeitet
werden.
Grundidee unserer Lösung:
* Wir zerlegen xRes in Zukunft in "packages". Jedes Package verfolgt
eine bestimmte Aufgabe (z.B. Logging, Buchung, Midoffice, Email,
...) und wird in einem eigenen Repo abgelegt.
* Die Abhängigkeiten der Packages untereinander lösen wir per
composer.json auf. Jedes Modul und Package bekommen eine solche
json-Datei und läd sich beim Build-Prozess die passenden
Abhängigkeiten hinzu.
* Die Abhängigkeiten werden dabei in jedes Modul als "vendor" abgelegt
=> was xRes im Dateisystem erheblich wachsen ließe.
Alternativ kann auch ein zentrales Vendor-Verzeichnis (mit Option
auf einen neuen Müllhaufen) erzeugt werden.
Die Umsetzung haben wir in diese Schritte / Reihenfolge gelegt:
1. Zuerst "reparieren" wir das DB-Deployment und vermeiden damit die
Probleme, die wir in allen vergangenen Releases mit der Reihenfolge
von Schema-Änderungs-Dateien hatten. In Zukunft werden Dateienamen
von Schema-Änderungen statt der durchlaufenden Nummer mit einem
Unix-Timestamp beginnen. Das DB-Deployment und der zugehörige
Unit-Test werden entsprechend angepasst.
2. Dann wird VBE ein erstes "Package" erzeugen und mit mir zusammen den
Build-Prozess erweitern. Über eine Mittwochs-Session werden wir dann
den Prozess des Umzugs von Code aus "modules" und "lib" in
"packages" abstimmen.
Der Ansatz für diesen Umzugsprozess ist es noch NICHT, Pakete auch
per composer.json zu laden. Statt dessen werden wir eine Anbindung
z.B. per git-submodules verwenden, dies wird den Umzug erleichtern
und Dependency-Probleme auf später verschieben.
Mit dieser Stufe hoffen wir, bis xRes 2.5 fertig zu sein.
3. Im nächsten Schritt wird die Config zentralisiert (also: alle
Konfigurationen einer xRes-Instanz). Es gibt dabei mehrere Ansätze,
die xResConf.xml statt des bisherigen Broadcast zu verteilen, auf
einer Maschine nur einmalig und zentral abzulegen und ggf. gar in
einem Repo automatisch zu versionieren.
In diesem Schritt sollte ferner das Verzeichnis "modules" entfernt
werden und damit das git-Repo der Verzeichnis-Struktur im
Livebetrieb angeglichen werden.
Nicht zuletzt wäre zu überlegen, ob wir in dieser Stufe des Umbaus
ein "webroot" einführen und allen anderen Code an eine Stelle
verschieben, die per Apache nicht erreichbar ist. Auf diese Weise
können wir die Sicherheit der Software erhöhen (besonders auf dem
Service01) und Logs ENDLICH auf die vorgesehene Daten-Partition
verschieben.
4. Im letzten Schritt wird die Paketierung auf das Abhängigkeits-System
umgestellt. Die Packages werden als Pakete gebaut, zentral abgelegt
und per composer zu einem Verzeichnisbaum zusammen geführt. Es muss
dafür einmalig aufgeschlüsselt werden, welches Package welche
anderen Packages benötigt und daraus eine composer.json erzeugt werden.
In diesem Schritt kann auch der Autoloader auf einen vom Composer
erzeugten Cache umgestellt werden.
5. Optional kann in einem zusätzlichen Arbeitsgang überlegt werden, ob
wir die Versionierung von Paketen zulassen wollen. Aktuell sieht es
nach einer nicht erforderlichen Komplexität aus, in Zukunft KÖNNTE
es aber hilfreich sein, von einem Package neben der neusten auch
alte Versionen vorliegen zu haben und diese in noch nicht
aktualisierten Modulen zu verwenden.
@VBE: DANKE für den Vorschlag!
VG SRK
--
Mit freundlichen Grüßen
Stefan Rank-Kunitz
- Lead Developer -
________________________________________________________
TraSo GmbH
Georg-Schumann-Str. 294
D-04159 Leipzig
Tel.: +49 341 355 740 - 43
E-Mail: s.rank-kunitz(a)traso.de
________________________________________________________
Handelsregister: Amtsgericht Leipzig, HRB 21850
