La versione breve
La produzione non segue automaticamente il branch più recente. Segue una decisione esplicita di promozione registrata nel ledger aziendale delle release.
Perché un Git SHA conta
Un Git SHA è un’impronta immutabile di uno specifico stato del codice sorgente. Quando PayCal approva una release, l’approvazione punta a uno SHA invece che a un nome di branch vago come main.
Questo ci dà una risposta precisa a una domanda pratica: l’applicazione in esecuzione è lo stesso codice approvato da PayCal Technologies?
I quattro record che confrontiamo
| Record | Significato |
|---|---|
| Record di release | Lo SHA sorgente ha superato i gate locali richiesti. |
| Stato desiderato | Il target deve eseguire questo SHA approvato. |
| Ricevuta di deploy | Lo script di deploy ha eseguito il checkout e ricaricato questo SHA. |
| Prova runtime | L’applicazione in esecuzione segnala questo SHA e il suo stato di salute. |
La release è pulita quando tutti e quattro concordano.
Cosa mostra lo stato pubblico
La pagina di stato pubblica mostra un riepilogo redatto: prodotto, stato di produzione, versione, ultimo orario verificato e se il runtime corrisponde alla release approvata. Non pubblica ricevute di deploy grezze, dettagli interni del server, identità degli operatori o log sensibili.
Perché questo aiuta i clienti
- I deploy sono deterministici: i target distribuiscono gli SHA esatti approvati.
- I punti di rollback sono espliciti: l’ultimo SHA runtime noto come valido è registrato per ogni target.
- Le prove di audit sono coerenti: approvazione, deploy e prova runtime possono essere confrontati.
- La deriva operativa è visibile: le mancate corrispondenze sono trattate come stati di indagine.