Sviluppo
Lo sviluppo remoto usa il workflow
Development operations.
È manuale, limitato a main, protetto dal GitHub Environment development e
serializzato dal gruppo di concorrenza dedicato.
Operazioni disponibili
| Operazione | Conferma esatta | Muta | Non muta |
|---|---|---|---|
preflight |
PREFLIGHT_DEVELOPMENT_ONLY |
nulla | D1, API, Frontend |
migrate-api-d1 |
MIGRATE_DEVELOPMENT_API_D1 |
solo D1 sviluppo | API e Frontend |
deploy-api-worker |
DEPLOY_DEVELOPMENT_API_WORKER |
solo API Worker | D1 e Frontend |
deploy-frontend-worker |
DEPLOY_DEVELOPMENT_FRONTEND_WORKER |
solo Frontend Worker | D1 e API |
Un run seleziona una sola riga. Le operazioni non si concatenano e una conferma errata non deve produrre un'azione alternativa.
Preflight
Il preflight esegue:
npm run check:development:operations
Il comando verifica la configurazione remota attesa, Access, domini distinti, assenza di marker di produzione, API e Frontend dry-run. La build Frontend usa un fixture API locale limitato: dimostra packaging deterministico, non parità con i dati o con l'API remota.
Deployment API
Il job API:
- ripete il controllo configurazione con
--require-access; - distribuisce soltanto
architecture-coffee-development; - mantiene D1 e Frontend invariati;
- esegue
npm run smoke:development, che legge/health,/versione/db/health.
Il risultato è valido solo se il Worker servito espone la revisione attesa e tutti e tre i controlli sono terminalmente verdi.
Deployment Frontend
Il job Frontend:
- costruisce l'export statico contro l'origine API di sviluppo;
- valida che il Worker sia asset-only e binding-free;
- distribuisce soltanto
architecture-coffee-frontend-development; - non migra D1 e non distribuisce l'API.
Il successivo smoke di cutover usa richieste GET limitate per HTML pubblico, metadata, 404, challenge Access, API, D1 e CORS Admin.
Percorso applicativo steady-state
L'Admin può richiedere un deployment Frontend di sviluppo usando soltanto l'azione proiettata dal server. In sviluppo la richiesta:
- convalida il candidato esatto di
main; - crea operation e attempt in D1;
- passa a
dispatching; - invia il workflow steady-state senza approvazione di produzione;
- conserva esito e run quando autorevoli.
La richiesta accettata è evidenza di avvio, non di successo. Vedere deployment Frontend dall'Admin.