• 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@traso.de
________________________________________________________
Handelsregister: Amtsgericht Leipzig, HRB 21850