Produzione

La produzione separa preflight, migrazione D1, deployment API, staging Frontend e attivazione Frontend. Nessuna fase autorizza automaticamente la successiva.

sequenceDiagram
    participant Fra
    participant Issue as Issue operativo
    participant GH as GitHub Environment production
    participant D1
    participant API as API Worker
    participant FE as Frontend Worker
    Fra->>Issue: go/no-go per il preflight
    Issue->>GH: preflight non mutante
    GH-->>Issue: evidenza sul commit esatto
    Fra->>Issue: autorizzazione migrazione se necessaria
    Issue->>GH: migrate-d1
    GH->>D1: applica solo migrazioni attese
    D1-->>Issue: risultato terminale
    Fra->>Issue: autorizzazione API
    Issue->>GH: deploy-api-worker
    GH->>API: distribuisce la revisione approvata
    API-->>Issue: health e D1 health
    Fra->>Issue: autorizzazione Frontend
    Issue->>GH: stage o steady-state
    GH->>FE: carica e attiva la versione esatta
    FE-->>Issue: smoke GET-only

Workflow operativo manuale

Production operations offre soltanto:

Operazione	Conferma esatta	Effetto
preflight	PREFLIGHT_ONLY	controlli e dry-run
migrate-d1	MIGRATE_PRODUCTION_D1	solo migrazioni D1
deploy-api-worker	DEPLOY_PRODUCTION_API_WORKER	solo API Worker
stage-frontend-version	STAGE_PRODUCTION_FRONTEND_VERSION	upload Frontend senza traffico

Lo staging non modifica percentuali, trigger o domini. L'attivazione è una decisione successiva e separata.

Produzione Frontend steady-state

Il percorso ordinario usa steady-state-frontend-deployment.yml tramite l'Admin:

1. la richiesta crea operation e attempt waiting_for_approval senza chiamare GitHub;
2. soltanto un'identità umana con deployment:approve riceve l'azione esatta;
3. l'approvazione rilegge main, persiste attore, tempo e commit, poi effettua un solo dispatch;
4. il workflow verifica che HEAD coincida con lo SHA richiesto;
5. costruisce, carica una versione taggata con il commit, la attiva al cento per cento ed esegue lo smoke limitato.

Il GitHub Environment protegge segreti ed esecuzione. L'approvazione umana canonica resta quella applicativa; non si presume un reviewer provider quando il piano repository non lo rende disponibile.

Preflight di produzione

npm run check:production

Il comando valida configurazione API/Frontend, domini, Access, CORS, assenza di segreti committati, Frontend binding-free e dry-run indipendenti. Non dimostra lo stato remoto e non autorizza il deployment.

Condizioni inderogabili

• usare un solo commit main con CI completa;
• registrare target di rollback API e Frontend prima della mutazione;
• elencare le migrazioni pendenti e applicare soltanto quelle autorizzate;
• non usare pubblicazione, Mailjet, Queue o dati editoriali come smoke;
• trattare provider timeout, run non univoco o versione non dimostrata come stato non riuscito;
• fermarsi tra le fasi per conservare evidenza e ottenere il go/no-go seguente.

Usare il runbook di produzione e, quando necessario, quello di staging e attivazione Frontend.