Release-Prozess

Release-Eingaben

Ein Release umfasst üblicherweise:

gebaute und veröffentlichte Container-Images
aktualisierte Dokumentation
Release Notes
optionale Änderungen am Migrationsdienst
optionale Änderungen am Client

Die optimierte Build-Architektur unterscheidet zwischen versionsabhängigen Payload-Images, gemeinsamen architekturabhängigen Runtime-Images und finalen, für Anwender bestimmten Komponenten-Images. Payload- und Runtime-Images sind Build-Abhängigkeiten; reguläre Installationen verwenden weiterhin die finalen Images.

Empfohlene Release-Schritte

Sicherstellen, dass das Repository fehlerfrei gebaut wird und die Wiki-Tests bestehen.
Verfügbarkeit der Server-, Client- und Firebird-Payload-Images prüfen.
Server- und GUI-Runtime-Images für die Zielarchitekturen prüfen.
Server-, Admin-, Client- und mRomexis-Images für die Zielarchitekturen prüfen.
Images für Migrationsdienst und Control Agent prüfen, sofern diese betroffen sind.
Multiarch-Manifeste prüfen.
Docker-Compose-Start testen.
Datenbankinitialisierung testen.
Start des Migrationsdienstes testen.
Release Notes erstellen.
Gitea-Release veröffentlichen.
Gitea-Pakete prüfen.

Zu prüfende Image-Ebenen

Ebene	Images	Zweck
Payload	`romexis-payload`, `romexis-client-payload`, `romexis-firebird-payload`	Versionsabhängige Installer-/Datenbankinhalte
Runtime	`romexis-base-jre`, `romexis-gui-runtime`	Wiederverwendbare architekturabhängige Abhängigkeiten
Final	`romexis-server`, `romexis-admin`, `romexis-client`, `romexis-mromexis-app`	Bereitstellbare Romexis-Komponenten
Dienste	`romexis-migration-service`, `romexis-control-agent`	Unabhängige unterstützende Dienste

Image-Prüfung

docker pull gitea.buchhorster.de/planmeca/romexis-server:<version>-amd64
docker pull gitea.buchhorster.de/planmeca/romexis-server:<version>

Untersuchen:

docker manifest inspect gitea.buchhorster.de/planmeca/romexis-server:<version>

Der öffentliche Multiarch-Tag wird erst veröffentlicht, nachdem die erforderlichen architekturspezifischen Staging-Images erfolgreich fertiggestellt wurden. Drone verwendet commitbezogene ci-<commit>-...-Staging-Tags und erstellt das öffentliche Manifest am Ende der Pipeline. Dadurch bleibt das vorherige öffentliche Manifest während eines laufenden Builds weiterhin pullbar.

Release Notes sollten Folgendes erwähnen

neue Funktionen
Änderungen am Migrationsdienst
Änderungen am Datenbank-Backend
Breaking Changes
erforderliche Änderungen an Umgebungsvariablen
bekannte Einschränkungen

Änderungen, die nur die internen Payload-/Runtime-Buildebenen betreffen, erfordern normalerweise keine Anpassung der Bereitstellung, solange die öffentlichen finalen Image-Namen, Tags und Laufzeitschnittstellen kompatibel bleiben.

Gitea-Bereiche

Gitea wird wie folgt verwendet:

Bereich	Zweck
Code	Quellcode und Dockerfiles
Releases	Menschenlesbare, versionierte Release Notes
Packages	Veröffentlichte Payload-, Runtime- und finale Container-Images
Wiki	Betriebs- und Entwicklerdokumentation
Issues	Fehler, Funktionswünsche und Planung