Vai al contenuto

Controlli ed evidenza

Un deployment è una catena di decisioni. Il repository distingue deliberatamente la prova che il codice è valido dalla decisione di mutare un ambiente.

flowchart LR
    modifica["Commit o pull request"] --> ci["CI"]
    ci --> validazione["Test, typecheck, build, dry-run e documentazione"]
    validazione --> verde["Evidenza repository verde"]
    verde -.->|"non autorizza"| remoto["Mutazione remota"]
    issue["Issue operativo in scope"] --> go["Go/no-go di Fra"]
    go --> workflow["Workflow manuale protetto"]
    workflow --> remoto
    remoto --> verifica["Verifica in sola lettura"]
    verifica --> evidenza["Evidenza sanitizzata nell'Issue"]

Gate prima della mutazione

  1. L'Issue operativo è aperto, in scope e autorizza esattamente l'operazione.
  2. Le dipendenze native sono chiuse e lo stato Project/Issue è coerente.
  3. Il commit è l'esatto main previsto e la CI completa è riuscita.
  4. Non esistono workflow, operation o finestre concorrenti sullo stesso ambiente.
  5. Sono registrati i target di rollback del solo componente coinvolto.
  6. Le migrazioni pendenti sono note; nessuna viene applicata implicitamente.
  7. Configurazione, route, Access, CORS e binding rispettano il contratto.
  8. Fra concede il go/no-go specifico; un'approvazione precedente non è riutilizzabile.

Project, Issue e dipendenze native

Per la delivery repository il flusso stabile è:

Project Label Issue aperto Significato
Backlog status:backlog pianificato, non eseguibile
Ready status:ready raffinato e ordinato da Fra
In progress status:in-progress branch e implementazione attivi
Review status:review draft PR in attesa di Fra
Done nessuna label workflow Issue chiuso dal merge
Blocked status:blocked stop esplicito

Lo stato Project non sostituisce il contenuto dell'Issue. Scope, acceptance criteria, autorizzazione, parent e dipendenze devono essere Issue-native. Una dipendenza aperta, uno stato discordante o un draft Project bloccano l'esecuzione. Le operazioni di produzione restano seriali anche quando la delivery repository consente due lane indipendenti.

Automatico, manuale e protetto

Azione Avvio Protezione Autorità
CI su pull request o push automatico contents: read, nessun Environment remoto valida soltanto
CI manuale workflow_dispatch stessa boundary non mutante valida soltanto
Operazioni sviluppo manuale Environment e concorrenza development Issue e go/no-go
Operazioni produzione manuale Environment e concorrenza production Issue e go/no-go per fase
Richiesta Frontend sviluppo azione Admin input server-owned e D1 permesso deployment:request
Richiesta Frontend produzione azione Admin nessun dispatch iniziale crea attesa di approvazione
Approvazione produzione azione umana separata deployment:approve, commit riletto Fra

Non esiste una mutazione remota autorizzata automaticamente dal successo della CI, da un push, da una pubblicazione editoriale o dalla disponibilità di un pulsante.

Controlli materiali

Controllo Scopo Rischio protetto Evidenza richiesta Fallimento
CI senza credenziali remote Validare il repository Deployment implicito da push run completo sul commit nessuna mutazione
Ref esatta main Bloccare revision drift Artefatto diverso da quello approvato SHA richiesto e checkout stop
GitHub Environment separati Isolare segreti ed esecuzione Cross-environment environment e workflow attesi stop
Una operation per run Separare migrazione e deploy Concatenazione non autorizzata input e conferma esatti job saltato o stop
Frontend binding-free Proteggere asset pubblici Esposizione di runtime o segreti dry-run e ispezione output stop
D1 health Provare connettività in lettura Worker sano con database rotto GET /db/health rollback o stop
Access e CORS esatto Conservare il confine Admin Accesso o origine allargati challenge e header attesi rollback o stop
Owner unico delle route Evitare routing ambiguo Risposte dal Worker sbagliato route matrix e smoke rollback o stop
Evidenza immutabile Ricostruire l'operazione Successo inventato o riscritto operation, attempt, run e commit stato unknown

Evidenza da associare

Conservare nell'Issue o nell'operation collegata soltanto dati sanitizzati:

  • SHA richiesto e SHA effettivamente servito;
  • nome del workflow, ambiente e tipo di operazione;
  • identificatore del run e URL GitHub quando autorevoli;
  • versione Worker precedente, caricata e attivata;
  • elenco delle migrazioni attese e risultato terminale;
  • risultato dei controlli health, D1, Access, CORS, route e pacchetto statico;
  • uso o mancato uso del rollback;
  • rischio residuo e condizioni non dimostrate.

Non conservare payload provider, credenziali, assertion Access, dati D1, identità personali o evidenza privata di produzione.

Autorizzazione singola e retry

Una finestra operativa esplicita è single-use: la prima mutazione consuma l'autorizzazione. Un fallimento o un risultato ambiguo non autorizzano una seconda esecuzione.

Il deployment Frontend applicativo può proiettare un'azione retry solo dopo uno stato terminale failed o cancelled. Questo retry:

  • richiede una nuova azione esplicita autorizzata dal server;
  • crea un nuovo attempt collegato;
  • non modifica l'attempt precedente;
  • non equivale a un retry automatico del workflow;
  • resta soggetto all'Issue e al go/no-go della nuova finestra.

Vedere deployment Frontend dall'Admin e gestione dell'evidenza ambigua.