Versionsverwaltung

Zusammenfassung

Wir brauchen eine Versionsverwaltung

Nutzen/Ziel

Diese muss sicherstellen, dass alle beteiligten Komponenten wissen, ob die verbundenen Teile auch funktionieren können.
D.h. grundsätzlich sind folgende Komponenten beteiligt

  • Datenbank
  • Applikations-Server / Wildfly
  • RestAPI
  • Terminal, mobile Applikationen
  • Swing-Client
  • zumindest teilweise die Reports

Es sollte so sein, dass jede Komponente weiß, welche seiner vorgelagerten Komponentenversionen es benötigt

Zugleich sollte es einen Updateautomaten geben, der die Ausrollung in der Form ermöglich, dass ein "normaler" Kieselstein ERP Administrator das Update auslösen kann. Dieses sollte dann, z.B. in der Nacht, nach dem (Komplett-) Backup sich automatisch einspielen. Wenn dann der Anwender seinen Client öffnet, sollte auch der Client quasi automatisch aktualisiert werden (Achtung auf Rechte, gerade bei ##10019/I)

Das bedeutet dass wir

  • eine Lösung für das Datenbankupdate brauchen, wie werden die ganzen Updatescripte erstellt / aufeinander aufbauernd oder ....
  • was passiert wenn, warum auch immer, das DB Update fehlschlägt
  • Jede Komponente muss faktisch von sich aus wissen welche Version es hat. Dies wird auch, für den normalen Anwender angezeigt und steht aber auch in den Fehlermeldungen drinnen

Wir sollten, zumindest für Windows, einen entsprechenden Installer haben, der alles vollständig automatisch einrichtet, quasi mit allen Regeln und der auch über Gruppenrichtlinien ausgerollt werden kann (was immer das heißen mag)

Was gehört alles dazu?

Die vorbereitete Trennung des Data und des Dist Verzeichnisses.
D.h. das Data ist Anwenderspezifisch, das dist (Distribution) kann immer quasi blind überschrieben werden, einzig das Datenbankupdate ist (manuell zu starten) auszuführen. In dem Datenbankupdate-Durchlauf sollten auch Hinweise für den Updatenden ausgegeben werden können. Z.B. im Report xyz ist folgendes zu prüfen. Das sollte später auch auf automatische Prüfungen von xyz ausgebauht werden können.

Data

Ins Dataverzeichnis gehören alle anwendungsspezifschen Daten wie z.B.:

  • Start des Servers (beider / aller Dienste)
  • Start weiterer Microservices -> in welchem Verzeichnis sind dann diese / Neben dem Wildfly? oder
  • das Clients mit der Browser-Schnittstelle/Darstelung, da hier ja auch Anwendungsspezifische Daten sind
    • weitere Programme die zum Kieselstein dazu gehören wie z.B. Terminal, VDA-Scann-App, Android-Mobile-App, die man dann von dort her updaten können sollte (oder so) und auch die passenden Java-Versionen bis hin zu readme.txt für Anwenderspezifische Beschreibungen
  • Jackrabitt und Datastore
  • die anwender Reports, auch die Fremdsprachigen -> das Root der Reports ist auf kieselstein umzustellen (ist zentral eine Stelle) Damit verbunden sollten die Kieselstein ERP Clients von sich aus erkennen, dass es neuere Clients unter .... gibt und ein Update erzwingen

Vom Gedanken wird das Data vom Anwender nach Beschreibung, die wiederum im Dist ist, zusammengestellt. Die grundlegenden Daten/Files sind, wie schon jetzt, im Dist und dienen als Muster für den Aufbau des Data.

Daran denken

  • ..\kieselstein\ejb\src\com\lp\server\res\lp.properties ... hier stecken die Server Versionsnamen drinne
  • ..\kieselstein\ejb\src\com\lp\server\res\lpconfig.properties .. hier sind die Report-Verzeichnisse definiert
  • ..\kieselstein\ejb\src\com\lp\server\res\lpconfig-os.properties ... bzw. hier
  • und auch in der lp_anwender

weiters

Es muss bei der Ausrollung der Reports das original Datum erhalten bleiben, sonst hat man als Consultant keine Change zu sehen welche neuen Reports man beachten muss / schulen muss usw.. Die Basis ist hier immer der Vergleich mit der Installation beim Anwender und der neu eingespielten / einzuspielenden Version

Edited by Alexis Sorbas