Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

"Geballtes Wissen" zu Thera-π

Über Thera-π

Installation

Bedienung

Hauptmenü

Stammdaten

Kassen

Ärzte

Patienten

Rezepte

Therapieberichte

  • Therapieberichte

Dokumentation

  • Dokumentation

Gutachten / E-Berichte

  • Gutachten und E-Berichte

Terminkalender

[Ru:gl]

  • Terminsuchmaschine

Nützliches...

  • Textbausteine – Therapieberichte
  • Textbausteine – Gutachten
  • Verkaufsmodul
  • Akutliste

Abrechnung privat und Kasse

OpenOffice - Tipps und Tricks

System Initialisierung

Backup / Datensicherung

  • Volle Sicherung, manuelle Durchführung
  • MySql-Tabellen einzeln sichern unter Linux
roadmap

Roadmap allgemein [für Entwickler]

Wer arbeitet woran?

  • Zip-and-Go, Start unter Linux: Jörg III. (Code of Conduct)
  • Klären der branch-bedingten Versionsverteilung im Code Repository
  • Welche Schritte fehlen noch für den Umstieg auf 64bit?

Roadmap Plattformunabhängikeit

Dies soll als Orientierung dienen, wie wir die Thera-Pi Software auch auf Linux und macOS verlässlich verfügbar machen können. Installation und Verwendbarkeit auf mobilen Geräten wie Smartphones und Tablets ist ein separates Thema.

Ziele

Die Ziele zur Herstellung der Plattformunabhängigkeit sind

  • Compilierbarkeit für die drei Targets windows, linux, macos (inkl. Anpassung des Builders dafür)
  • Erstellen von Installationspaketen (z.B. ZIP für Windows, DEB- und RPM-Pakete für Linux)
  • einfache Installation auf den drei Plattformen (inkl. einfacher Anleitung üfr due Nutzer)

Hierbei geht es vorerst um die 32bit-Version der Software. Die Überführung in eine verlässlich compilierende und funktionierende Version wird hier nicht behandelt.

Mehrstufiges Vorgehen

Aus dem Forum, Chat und Gitlab Issues geht hervor, dass bereits mehrfach versucht wurde, die Plattformunabhängigkeit herzustellen, dies bisher aber noch nicht zu einem zufriedenstellenden Ergebnis gelangt ist. Da sich auch Linux und macOS in einigen Punkten unterscheiden und bereits mehrere Probleme beim Installieren und Ausführen der Software auf Linux zeigten, bietet sich eine mehrstufige Vorgehensweisen an, das Ziel zu erreichen.

Separates Vorgehen für Linux und macOS

Als unixoide Betriebssysteme sind sich Linux und macOS „unter der Haube“ recht ähnlich. Dennoch unterscheiden sie sich in mehreren Punkten, welche möglicherweise in der Konzeption der Software noch nicht erfasst sind. Da sich die Software viel einfacher und kostenfrei unter Linux (z.B. in VirtualBox VMs sowohl für 32bit als auch 64bit) testen lässt, als auf Apple Hard- und Software, bietet sich an, die Portabilitätsprobleme zuerst für Linux zu beheben. Damit sollten, wenn überhaupt, nur noch wenige macOS-spezifische Punkte verbleiben, die im Anschluss angegangen werden können.

Linux

Konfiguration
  • Sämtliche im Quellcode hinterlegten Pfade sollten in java-tauglicher plattformunabhängiger Form hinterlegt sein. D.h. es sollten keine Backslashes verwendet werden.
    • a) via File.separator (etwas Overhead, schlechter lesbar, nicht wirklich notwendig)
    • b) durch konsistente Verwendung des „/“ in allen Pfadangaben (der gängige Weg, da dies immer auf allen Hos-Pplattformen von der installierten JVM/JRE korrekt interpretiert wird, einfacher lesbar/pflegbar)
  • Alle Pfadangaben sollten an zentraler konfigurationsbezogener Stelle hinterlegt sein - nicht mehr hart-kodiert an der Stelle im Code, wo sie jeweils benötigt werden.
Bibliotheken
  • Identifizieren aller DLL (Windows-spezifisch dynamisch gelinkte Bibliotheken)
  • Bereitstellen der entsprechenden .so Libraries für Linux
Installationspakete (DEB/RPM)

Für eine einfache Installation der Software auf gängigen Linuxdistributionen sollten DEB- und RPM-Pakete im automatischen Build-Prozess erstellt werden.

macOS

  • Ausprobieren einer Zip & Go Installation auf macOS
  • ggf. Erstellen eines Installers oder macOS-spezifischen Software-Pakets
  • Nach Erreichen der Plattformunabhängikeit für Windows und Linux können noch auftretende Probleme auf macOS angegangen werden.

Roadmap Testing

Um für zukünftige Releases neuer Features oder Versionen der Software relativ zeitnah zu gewährleisten, dass bestehende grundlegende Funktionalität und Neuerungen vor Veröffentlichung getestet wurden, bietet sich folgendes Testkonzept an:

  • Unit Tests
    • Evaluation der bisherigen Testabdeckung durch Unit Tests (JUnit) z.B. mittels GitLab Tools (wobei momentan eine ausreichende Unit-Test-Abdeckung durch die involvierten Entwicker nicht gewährleistbar scheint)
  • Integrations-/End-to-End Tests
    • Use Casses
      • Sammeln der bestehenden Nutzerszenarien (Starten der Anwedung, Klienten anlegen etc.)
        • auch der negativen Varianten (was soll passieren, wenn etwas schief läuft, was soll gelogt werden, Fehlerausgaben für Nutzer)
      • Beschreibung neuer Features als Nutzerszenarien, wenn neue Entwicklungen anstehen
      • Konkrete Ausformulierung der Nutzerszenarien
        • Ausgangsbedingung (leeres System, vorausgesetzte Konfiguration und Daten)
        • Schritte für Durchlauf des Szenarios
        • Erwartung nach Durchlauf des Szenarios
      • Automatiserte Einbindung der Tests in GitLab CI/CD Pipeline
        • Erstellen eines Testsytems bei jedem größeren Build (neues Feature oder für neue Version)
        • automatisierte Testinfrastrukten können in den GitLab Deployment-Ablauf eingebunden werden (und somit bei Merges und Releases als Qualitätsschwelle eingesetzt werden)
        • anhand der Nutzerszenarien können mit dem keyword-basierten Testframework Robotframework und seiner Bibliothek für Tests von GUI-basierten Java-Anwendungen automatisierte menschenlesbare End-to-End Tests erstellt werden
roadmap.txt · Zuletzt geändert: 2022/03/16 21:46 von mahula