Content-addressed Identität
Kanonischer Release-Inhalt wird gehasht und erhält eine stabile Identität für das Artefakt, das Betreiber prüfen und promoten.
Deterministische Releases
Promote genau das Artefakt, das geprüft wurde.
Relpin macht aus jedem Capsule-Publish ein content-addressed Release, das an seinen Schema-Kontext gepinnt ist. TEST und PROD erhalten das governed Artefakt durch freigabegesteuerte Promotion, nicht durch einen neuen Build aus veränderlichem Editor-Zustand.
Release record
pinned
- ARTIFACT
- sha256:9f2c4e81…d41a1
- PLATFORM SCHEMA
- v41 · pinned
- ORG SCHEMA
- v7 · pinned
- APPROVALS
- bound to artifact hash
identical content re-publishes as a no-op · version records append-only
Das Release-Problem
Ein erfolgreicher Build beweist nicht, dass Produktion dieselbe Software erhalten hat.
Interne Tools durchlaufen oft kopierte Konfiguration, Ad-hoc-Rebuilds und direkte Änderungen pro Umgebung. Dadurch werden Review-Nachweise schwer vertrauenswürdig und Rollback-Entscheidungen schwer erklärbar.
Release-Kontrollen
Determinismus wird an der Promotion-Grenze erzwungen.
Der Release-Pfad verbindet unveränderliche Identität, Umgebungsregeln und Prüfung zum Apply-Zeitpunkt.
Freigabegebundene Promotion
TEST und PROD folgen expliziten Freigaberegeln. Eine Neuplanung ändert den Artefakt-Kontext und entwertet veraltete Freigabe-Nachweise.
Fail-closed Drift-Prüfungen
Die Promotion prüft den Ziel-Schema-Kontext, bevor der Deployment-Zeiger wechselt. Drift stoppt den Vorgang, statt das Release stillschweigend abzuschwächen.
Betriebsmodell
Einmal bauen. Die exakte Einheit prüfen. Durch Regeln promoten.
Capsules halten App-Code und eigene Datenänderungen innerhalb einer governed Promotion-Grenze.
- 01
In DEV publishen
Relpin erfasst Capsule-Release, benötigte Capabilities, Build-Ausgabe und gepinnten Schema-Kontext.
- 02
Für die Zielumgebung prüfen
Betreiber prüfen das geplante Artefakt und die Schema-Änderungen, bevor die von der Regel verlangten Freigaben erteilt werden.
- 03
Ohne Bypass anwenden
Der Worker prüft Drift und Deployment-Eingaben, führt bei Bedarf governed Schema-Arbeit aus und schaltet dann das Ziel-Deployment um.
Release-Nachweise
Content-addressed Capsule-Release
DEV → TEST → PROD State Machine
Freigabe- und Funktionstrennungsregeln
Unveränderliche Promotion-Ereignislinie
Release-Fragen
Was deterministische Promotion für Betreiber verändert.
Baut Relpin eine App während der Promotion neu?
Die Promotion verwendet das governed Release und den deploybaren Build der Quellumgebung. Veränderlicher Editor-Zustand wird im Ziel nicht als Produktions-Release akzeptiert.
Was passiert, wenn sich das Ziel-Schema geändert hat?
Drift-Prüfungen zum Apply-Zeitpunkt stoppen die Promotion, wenn ihre gepinnten Annahmen nicht mehr passen. Betreiber erstellen oder planen sie gegen den aktuellen Zustand neu.
Können TEST oder PROD die Promotion umgehen?
Der governed Pfad blockiert direkte Mutationen in TEST und PROD standardmäßig. Promotion ist der nutzerseitige Weg, eine Capsule weiterzuschalten.
Standardmäßig gepinnt
Mache Release-Nachweise zum Teil des Runtime-Pfads.
Baue interne Tools als echten Code und bewege sie durch deterministische Promotion, ohne das geprüfte Artefakt zu verlieren.
Open Beta · Kein SLA