Kurzfassung
Die Produktion folgt nicht automatisch dem neuesten Branch. Sie folgt einer ausdrücklichen Promotion-Entscheidung, die im unternehmenseigenen Release-Ledger aufgezeichnet ist.
Warum ein Git SHA wichtig ist
Ein Git SHA ist ein unveränderlicher Fingerabdruck eines bestimmten Quellzustands. Wenn PayCal ein Release genehmigt, verweist die Genehmigung auf einen SHA statt auf einen ungenauen Branch-Namen wie main.
Damit erhalten wir eine präzise Antwort auf eine praktische Frage: Läuft in der Anwendung derselbe Code, den PayCal Technologies genehmigt hat?
Die vier Datensätze, die wir vergleichen
| Datensatz | Bedeutung |
|---|---|
| Release-Datensatz | Der Quell-SHA hat die erforderlichen lokalen Gates bestanden. |
| Sollzustand | Das Ziel soll diesen genehmigten SHA ausführen. |
| Deployment-Beleg | Das Deployment-Skript hat diesen SHA ausgecheckt und neu geladen. |
| Laufzeitnachweis | Die laufende Anwendung meldet diesen SHA und ihren Gesundheitszustand. |
Das Release ist sauber, wenn alle vier übereinstimmen.
Was der öffentliche Status zeigt
Die öffentliche Statusseite zeigt eine redigierte Zusammenfassung: Produkt, Produktionsstatus, Version, Zeitpunkt der letzten Prüfung und ob die Laufzeit mit dem genehmigten Release übereinstimmt. Sie veröffentlicht keine rohen Deployment-Belege, Serverinterna, Betreiberidentitäten oder sensiblen Logs.
Warum das Kunden hilft
- Deployments sind deterministisch: Ziele deployen exakt genehmigte SHAs.
- Rollback-Punkte sind explizit: Der letzte als gut bekannte Laufzeit-SHA wird je Ziel aufgezeichnet.
- Audit-Nachweise sind kohärent: Genehmigung, Deployment und Laufzeitnachweis können verglichen werden.
- Operative Abweichungen werden sichtbar: Nichtübereinstimmungen gelten als Untersuchungszustände.