DEPLOYMENT-CONTRACT-MODEL

Deployment-Vertragsmodell#

Übersicht · 2: zweite Ebene · Ziehen/Klicken: navigieren

Aussage#

Ein Deployment ist eine koordinierte Runtime-Transaktion. Es überführt einen eindeutig identifizierten Build-Kandidaten in einen Zielzustand, prüft jede zustandsändernde Phase, erzeugt versiegelte und endet entweder mit einem verifizierten Commit oder einem dokumentierten Fehler- und Recovery-Zustand.

Pflichtphasen#

Plan → Preflight → Recovery Point → Quiesce → Install → Configure
                → Start → Health → Readiness → Functional Smoke → Evidence → Commit

Verbindliche Regeln#

Build-Artefakte und Zielumgebung sind vor der ersten Zustandsänderung eindeutig bestimmt.
Ein Recovery Point existiert vor Installation oder Migration.
Binary, Frontend, Konfiguration und Metadaten werden als eine koordinierte Transaktion behandelt.
Health allein ist kein Versions-, Readiness- oder Funktionsnachweis.
Erfolg setzt materialisierten Zielzustand, beobachtete Verifikation und versiegelte Evidence voraus.
Fehler führen zu Rollback oder zu einem expliziten manual_recovery_required-Zustand.
Deployment-Erfolg ist noch keine Production-Promotion; bleibt ein getrenntes Gate.
Runtime-Evidence belegt eine konkrete Ausführung, definiert aber den Vertrag nicht neu.

Rollen#

Enterprise Architecture besitzt die kanonische Semantik.
Solution Architecture spezialisiert Ziel, Phasen und Nachweise.
Engineering Platform besitzt den produktbezogenen Deployment-Vertrag.
Engineering Tools besitzt die ausführbare Deployment- und Validierungsmechanik.
Runtime besitzt nur Materialisierung, Zustand und Evidence.