Clone
2
Developer Guide.de
Patrick Gniza edited this page 2026-08-21 09:04:39 +02:00

Deutsch | English

Entwicklerhandbuch

Diese Seite beschreibt die interne Projektstruktur und den Entwicklungsworkflow.


Hauptverzeichnisse des Projekts

romexis-common/
  Shared Java agent, patches and native helper sources.

romexis-base/
  Shared Romexis Server runtime image.

romexis-gui-runtime/
  Shared GUI runtime for Romexis Admin and Client.

romexis-payload/
  Windows installer payload extraction for Server/Admin/mRomexis.

romexis-client-payload/
  Version-specific Romexis Client payload image.

romexis-firebird-payload/
  macOS Firebird SQL payload extraction.

romexis/
  Final Romexis Server image.

romexis-admin/
  Final Romexis Admin image.

romexis-client/
  Final standalone Romexis Client image.

romexis-mromexis-app/
  Final mRomexis Web App image.

romexis-control-agent/
  Restricted container control API.

migration-service/
  Migration Web UI, REST API, SFTP and restore orchestration.

migration-client/
  Source-side migration helper client.

scripts/
  Local and CI build helpers.

docs/
  Extended markdown documentation.

Entwicklungsgrundsätze

  • Proprietäre Binärdateien aus Git fernhalten.
  • Versionsabhängige Installerextraktion in Payload-Images belassen.
  • Aufwendige architekturabhängige Abhängigkeiten in gemeinsamen Runtime-Images belassen.
  • Gemeinsame Agent-, Patch- und native Hilfsquellen in romexis-common/ pflegen.
  • Die finalen Server-, Admin- und Client-Images auf Zusammenbau und Laufzeitlogik konzentrieren.
  • Romexis Admin und Romexis Client als unabhängige finale Images auf Basis derselben GUI-Runtime halten.
  • MSSQL- und Firebird-Initialisierung getrennt halten.
  • Das Wrapper-Skript ausschließlich für das Backend-Routing verwenden.
  • Explizite Validierung gegenüber still erzeugten, unvollständigen Images bevorzugen.

Build-Abhängigkeitsmodell

Der Build ist bewusst in drei Ebenen aufgeteilt:

  1. Payload-Images enthalten versionsabhängige Inhalte aus dem Romexis-Installer.
  2. Runtime-Images enthalten wiederverwendbare architekturabhängige Betriebssystem- und Bibliotheksabhängigkeiten.
  3. Finale Images kombinieren Payload und Runtime mit den komponentenspezifischen Skripten.

Dadurch bleiben sowohl die umfangreiche Installerextraktion als auch die aufwendige Runtime-Vorbereitung über Server-, Admin- und Client-Builds hinweg wiederverwendbar. Reine Payload- und Runtime-Build-Images sind keine zusätzlichen Laufzeitdienste in Docker Compose.

Für lokale Entwicklung werden scripts/build-local.sh oder scripts/build-local.ps1 verwendet. Drone nutzt dasselbe Abhängigkeitsmodell mit unveränderlichen commitbezogenen Staging-Tags und Registry-basierten BuildKit-Caches.


Datenbankinitialisierungsskripte

init-romexis-db.sh
  Routes to backend-specific init script.

init-romexis-mssql-db.sh
  Handles SQL Server initialization.

init-romexis-firebird-db.sh
  Handles Firebird initialization.

Versionsabhängige Datenbankaktualisierungen

Die Datenbankinitialisierungsskripte verwenden eine explizite Romexis-Aktualisierungsreihenfolge.

Dies ist erforderlich, weil sich die Markierungen nicht numerisch sortieren lassen.

Beispiel:

600, 610, 63, 64, 651, 652, 653

Das Skript ermittelt die Zielmarkierung aus /opt/romexis/version und führt Aktualisierungen bis zu dieser Markierung aus.


Image-Inhalte testen

docker run --rm --entrypoint find \
  gitea.buchhorster.de/planmeca/romexis-server:<tag> \
  /opt -maxdepth 3 -type f | sort

Shell öffnen:

docker run --rm -it --entrypoint bash \
  gitea.buchhorster.de/planmeca/romexis-server:<tag>

Lokales Debug-Compose-Override

services:
  romexis:
    entrypoint:
      - /bin/bash
      - -c
      - sleep infinity
    stdin_open: true
    tty: true

Anschließend:

docker compose exec romexis bash