Vai al contenuto

Deployment Frontend dall'Admin

Il workspace Admin non accetta repository, workflow, ref, conferme GitHub o input arbitrari. L'API proietta l'azione esatta e mantiene credenziali, dispatch, approvazione e riconciliazione sul server.

sequenceDiagram
    participant U as Operatore Admin
    participant API
    participant D1
    participant GH as GitHub Actions
    U->>API: legge capability e azione proiettata
    U->>API: richiede commit esatto
    API->>D1: crea operation e attempt
    alt sviluppo
        API->>GH: dispatch immediato singolo
    else produzione
        API-->>U: waiting_for_approval
        U->>API: approva operation e commit esatti
        API->>D1: persiste evidenza di approvazione
        API->>GH: dispatch singolo
    end
    GH-->>API: evidenza disponibile o ambigua
    U->>API: riconcilia solo se proiettato
    API->>GH: legge il run autorevole
    API->>D1: transizione atomica e readback

Stati di operation e attempt

stateDiagram-v2
    [*] --> requested: sviluppo
    [*] --> waiting_for_approval: produzione
    requested --> dispatching
    waiting_for_approval --> dispatching: approvazione umana
    dispatching --> queued
    dispatching --> unknown: evidenza ambigua
    queued --> running
    running --> succeeded
    running --> failed
    running --> cancelled
    queued --> unknown
    unknown --> queued: riconciliazione
    unknown --> running: riconciliazione
    unknown --> succeeded: riconciliazione
    unknown --> failed: riconciliazione
    failed --> requested: nuovo attempt autorizzato
    cancelled --> requested: nuovo attempt autorizzato

Gli stati terminali succeeded, failed e cancelled sono immutabili. Lo stato unknown significa che l'evidenza provider non consente una conclusione, non che il deployment sia riuscito.

Persistenza

  • operation e primo attempt sono creati nello stesso batch D1;
  • un indice univoco impedisce più operation attive nello stesso ambiente;
  • operation e attempt cambiano stato in coppia con lo stesso marker;
  • l'approvazione di produzione è completa, coerente e immutabile;
  • un run URL è accettato soltanto se appartiene al repository e al run registrato;
  • il readback deve confermare stato ed evidenza dopo ogni transizione.

Un errore D1 non viene reinterpretato come conflitto a meno che una lettura autorevole dimostri un'operation attiva. In assenza di prova il risultato resta neutro e il provider non viene chiamato.

Approvazione di produzione

L'approvazione richiede:

  • identità umana;
  • permesso deployment:approve;
  • stesso operation ID, commit e conferma proiettati;
  • operation ancora waiting_for_approval;
  • capability produzione abilitata e main invariato.

Un'identità service non può approvare anche se una configurazione errata le elencasse il permesso.

Riconciliazione

La riconciliazione:

  1. è disponibile soltanto per stati attivi o unknown;
  2. usa l'eventuale run ID già registrato oppure cerca un unico run compatibile;
  3. verifica workflow, branch, evento e commit;
  4. persiste la transizione senza creare una nuova operation o un retry;
  5. fallisce chiusa se il provider o D1 non sono autorevoli.

Usare il runbook di riconciliazione.