Relpin publisht content-addressed Releases: Jeder Publish kanonisiert das Bundle, hasht es mit SHA-256 und pinnt es an die exakten Platform- und org-Schema-Versionen. Dasselbe Artefakt wird über Umgebungen hinweg promotet, statt neu gebaut zu werden.
identical content re-publishes as a no-op · version records append-only
Die meisten Internal-Tool-Plattformen shippen das, was der Editor gerade enthält. Ein deterministisches Release pinnt einen exakten Artefakt-Hash an eine exakte Schema-Version, sodass das, was in TEST geprüft wurde, Byte für Byte das ist, was in PROD läuft.
Jeder Publish kanonisiert das Bundle zu stabilem JSON und hasht es mit SHA-256. Der Hash ist die Identität des Release, sodass identischer Inhalt als No-op erneut publisht wird und es keine Mehrdeutigkeit darüber gibt, auf welches Artefakt ein Versionsdatensatz zeigt.
Versionsdatensätze sind append-only und an die exakte Platform-Version und org-Schema-Version gepinnt, gegen die sie gebaut wurden. Ein Release ist kein beweglicher Zeiger auf den neuesten Editor-Zustand, sondern ein festes Artefakt, das an das von ihm erwartete Schema gebunden ist.
DEV, TEST und PROD teilen sich ein content-addressed Artefakt. Die Promotion klont genau dieses Artefakt in die Zielumgebung, statt neu zu bauen, und fällt bei Schema-Drift, das zum Apply-Zeitpunkt erneut geprüft wird, fail-closed aus. Freigaben sind an den Artefakt-Hash gebunden, sodass ein erneutes Planen sie ungültig macht.
Alle Kategorie-Guides fuer Internal Tool Builder, AI Agents, Low-Code-Grenzen und Produktionsdaten.
Governed Internal ToolsWie sich gepinnte Releases in das umfassendere Governance-Modell einfügen.
Audit-ready Internal ToolsWie Promotion-Entscheidungen neben Datenänderungen auditiert werden.
Retool-AlternativeVergleichen Sie Release-Pinning mit einer visuellen Internal-Tool-Plattform.
Plattform-GlossarDefinitionen für die hier verwendeten Release- und Governance-Begriffe.
In Relpin ist ein deterministisches Release ein content-addressed Artefakt: Jeder Publish kanonisiert das Bundle zu stabilem JSON, hasht es mit SHA-256 und pinnt den Versionsdatensatz an die exakten Platform- und org-Schema-Versionen. Dasselbe Artefakt wird über Umgebungen hinweg promotet, statt neu gebaut zu werden.
Da Releases content-addressed sind, erzeugt identischer Inhalt denselben SHA-256-Hash und wird als No-op erneut publisht. Ein neuer Versionsdatensatz entsteht nur, wenn sich das kanonisierte Bundle tatsächlich ändert.
Deployment-Zeiger sind forward-only; es gibt keine Rollback-Operation. Releases werden gepinnt und vorwärts durch DEV, TEST und PROD promotet, und die Promotion fällt bei Schema-Drift, das zum Apply-Zeitpunkt erneut geprüft wird, fail-closed aus.