Vai al contenuto

Deployment e operazioni

Questa sezione descrive il contratto operativo corrente di Architecture Coffee. Spiega come validare, migrare, distribuire, attivare, riconciliare e ripristinare i componenti senza ricostruire la procedura da Issue storici o file workflow.

La documentazione non è un'autorizzazione

Un comando disponibile o un workflow verde non autorizzano una mutazione remota. Ogni operazione su sviluppo o produzione richiede un Issue operativo esplicito, i gate descritti in questa sezione e il go/no-go di Fra.

Principi invarianti

  • CI valida il repository e non distribuisce.
  • D1, API Worker e Frontend Worker hanno operazioni e rollback separati.
  • development e production usano GitHub Environment, credenziali e concorrenza distinti.
  • Il commit richiesto, l'artefatto costruito e la versione attivata devono riferirsi alla stessa revisione autorevole.
  • Un risultato assente, parziale o ambiguo non è successo.
  • Lo smoke test è limitato e in sola lettura; non pubblica, non invia email e non crea dati editoriali.
  • Il rollback ripristina un solo componente e non corregge lo schema D1.

I diagrammi mantengono testo leggibile su schermi stretti e possono scorrere orizzontalmente quando la topologia non entra nella larghezza disponibile.

Percorso di lettura

  1. Topologia e responsabilità per capire chi possiede host, runtime, dati e autenticazione.
  2. Controlli ed evidenza per distinguere validazione, autorizzazione ed esecuzione.
  3. Sviluppo, produzione e migrazioni D1 per i percorsi separati.
  4. Deployment Frontend dall'Admin per il flusso applicativo steady-state e la riconciliazione.
  5. Rollback e recupero per trigger, confini e decisioni.
  6. I runbook operativi per eseguire una finestra autorizzata: sviluppo, produzione, migrazione D1, staging e attivazione Frontend, riconciliazione, rollback API, rollback Frontend, evidenza ambigua e smoke test limitato.

Fonti canoniche

La prosa del portale interpreta, ma non sostituisce: