Produktupdates ohne manuelle Nacharbeit

Workspace führt bei einem unterstützten Update alle sicheren, produktbesessenen Übergänge selbst aus. Sie müssen keine Datenbankspalten, Systemartefakte, Taskstream-Sources oder Revisionsanker einzeln prüfen und keine Apply-Befehle aus Release-Notizen ableiten.

Update durchführen

  1. Erstellen Sie die für Ihre Betriebsform vorgesehene Sicherung.
  2. Beenden Sie die alte Workspace-Version.
  3. Installieren oder starten Sie die neue offizielle Workspace-Version.
  4. Warten Sie mit dem geschützten Serververtrag auf den Abschluss:
bash
   nucli --tenant system system product-release status --watch
  1. Prüfen Sie, dass /health/ready mit HTTP 200 antwortet.

Während Workspace den Releasevertrag abgleicht, bleibt /health/live erreichbar. /health/ready antwortet bis zur vollständigen Verifikation mit HTTP 503. /health/product-release zeigt dabei den begrenzten Maintenance-Zustand. Worker, Analytics-, SFTP- und SMTP-Laufzeiten sowie Business-Routen starten erst nach der Verifikation.

Ein normaler Updateablauf benötigt kein numin ... --apply, kein system-init apply, keinen direkten Datenbankzugriff und keine aus Release-Notizen erratene Reihenfolge von Wartungsschritten.

Was Workspace automatisch prüft

Der mit der Binary ausgelieferte Releasevertrag bindet das unterstützte Schema- und Vertragsfenster, globale Systemartefakte, die Workflow-Bibliothek, den Taskstream-Katalog, Executor, Scheduler, Producer-Sources sowie positive Tenant- und IAM-Revisionsanker. Er prüft zudem alle gepinnten Workflow-Versionen aller nicht gelöschten Tenants. Übersprungene Zwischenreleases spielen keine Rolle, solange der letzte vollständig verifizierte Stand im unterstützten Fenster liegt.

Workspace plant zuerst den gesamten Übergang. Erst wenn dieser Preflight keine Konflikte findet, wendet der Server die als automatic_safe deklarierten Schritte an. Jeder Schritt ist persistent, idempotent sowie durch Lease und Fence-Token gegen parallele Instanzen geschützt. Mehrere Instanzen teilen denselben Tenant-Snapshot und denselben Release-Run. Inkompatible alte Instanzen beenden neue Arbeit, warten laufende Taskstream- und Workflow-Artefaktversuche ab und wechseln vor der Mutation in drained.

Einen blockierten Updatezustand prüfen

Vorhandene ungültige Revisionen, inaktive Producer-Sources, unbekannte persistierte Taskstream-Typen, nicht kompilierbare Workflows und inkompatible kundeneigene Overlays bleiben absichtlich unverändert.

bash
nucli --tenant system system product-release status --json

Der geschützte Status-Endpunkt bleibt auch während des Product-Release-Gates erreichbar. Er zeigt Run, Retry-Zeitpunkt, Tenant-Snapshot, Komponenten, Runtime-Evidenz und Blocker mit verantwortlichem Bereich und nächster Aktion. Die Antwort enthält keine SQL-, Pfad-, Treiber- oder Secret-Details. numin bleibt die lokale, read-only Diagnose für eine privilegierte Betriebsumgebung; für einen erreichbaren Server verwenden Sie nucli.

Beheben Sie den gemeldeten fachlichen Konflikt über den vorgesehenen Produktvertrag und starten Sie dieselbe Binary erneut. Der Release-Run setzt an seinen verifizierten Checkpoints fort.

Neue Tenants

Neue Tenants verwenden automatisch standard.v1 mit iam, workflows, crm, localization, commerce, pim und forum. Workspace legt positive Autorisierungsanker vor dem ersten Producer- oder Job-Artefakt an. Business- Routen bleiben gesperrt, bis alle Profilschritte verifiziert wurden.

POST /api/v1/system/tenants legt Tenant, Eigentümerbindung und Provisionierungs-Run atomar an. Senden Sie für Automatisierungen einen Idempotency-Key. Workspace antwortet mit HTTP 202, Location, Retry-After, Tenant, Run und Status-URL. Derselbe Schlüssel mit demselben normalisierten Request liefert denselben Run; ein anderer Request mit diesem Schlüssel liefert HTTP 409.

Systemadministratoren lesen den Zustand mit nucli --tenant system system tenant-provisioning status <tenant-id> oder unter GET /api/v1/system/tenants/{tenant-id}/provisioning. Unterbrochene Läufe werden paginiert, mit dauerhaftem Backoff und auf demselben Run fortgesetzt. GET /api/v1/system/tenants?include=provisioning ergänzt den jeweils letzten Zustand für eine paginierte Tenant-Liste mit einer einzigen Batch-Abfrage. Business-Routen bleiben bis succeeded gesperrt.