03 - Modello del componente

Indice · Sviluppo e rilascio

Ora fissiamo lo standard; dettagliamo ogni componente mentre lo sviluppiamo e prima del suo primo deploy. Non occorre completare Farm, Releases, Console o tutte le schede future per dividere il lavoro.

Lo sviluppatore propone risorse e accessi, Dockerfile/script/test e manifest. Jacopo e Lorenzo completano insieme la registrazione cloud e consegnano il kit; poi le release ordinarie non richiedono di ripetere l'onboarding.

Un sistema può contenere backend, migratore e worker: la scheda descrive un componente eseguibile e le sue dipendenze. Una libreria, invece, non riceve automaticamente un servizio cloud.

Quando definire le informazioni

Momento	Informazioni necessarie
Ora: standard condiviso	Distinzione sistema/componente, profili ammessi, separazione runtime/migratore, accessi espliciti e criteri comuni di collaudo. I valori sconosciuti restano «da definire».
Durante lo sviluppo	Repository/directory, referente, Service o Job, dati utilizzati, chiamanti/destinatari, migrazioni, capacità cloud e limiti necessari. Verificare presto eventuali profili non supportati.
Prima del primo deploy	Nomi e identità effettivi, risorse/permessi applicati, baseline SQL se necessaria, manifest senza segnaposto, contratti coerenti, immagini verificate e piano di collaudo/recupero. Nessuna ambiguità sui privilegi.

Scheda da copiare

Questo è un promemoria Markdown descrittivo, non un nuovo formato eseguibile o un file letto da Terraform. Riportare riferimenti ai cataloghi; non duplicare manualmente tutti i loro valori.

Sistema / componente / referente:
Repository e directory:
Profilo build / delivery:
Destinazione e identità: riferimento al catalogo Terraform
Dati e capacità: DB/ruolo, bucket, segreti per riferimento, eventi
Chiamanti e destinatari: rete, identità, operazioni consentite
Schema richiesto, compatibilità e referente delle migrazioni (se SQL):
Altre dipendenze:
Limiti, prove attese e recupero:
Stato: da definire / predisposto / collaudato, con evidenza

Non inserire password, chiavi o token. IAM e autorizzazioni applicative rimangono distinti: accessi.

Dove diventano configurazione

• Catalogo stage: system_catalog e risorse/capacità dei componenti.
• Configurazione bootstrap: application_repositories per sorgenti/build; application_deliveries per le nuove delivery, secondo il modulo comune.
• Configurazione stage: runtime_deliveries, enrollment/baseline SQL ed eventuali eventi richiesti.

I contratti delivery/runtime/operator sono output generati da confrontare e consegnare all'operatore, non nuovi JSON da scrivere a mano. Un nuovo componente richiede registrazioni revisionate; le successive release ordinarie riusano quelle risorse.

Una delivery per componente (decisione dell'11 novembre 2026): backend, consumer, relay, sweeper, Dev ORM e ogni Job di un sistema sono delivery distinte, ciascuna con la propria release, anche nella stessa repository; il Job migratore resta nella delivery del backend, che lo esegue per primo. Gli ID di delivery sono corti, al massimo 11 caratteri (per esempio acc-relay, rel-sweep), perché entrano nei nomi delle risorse cloud. I nomi effettivi si fissano insieme prima di registrare qualunque delivery.

Per i componenti che adottano il nuovo controllo, la repository applicativa contiene un file di requisiti per delivery, deploy/runtime-requirements/<delivery-id>.json, che copre esattamente i componenti di quella delivery; un file unico per repository viene rifiutato. Dichiara le variabili richieste e vietate, non assegna permessi. Il manifest è il riferimento approvato per lo stage; il codice si adatta a quel contratto. Una funzionalità che necessita di nuove risorse comporta un aggiornamento coordinato di requisiti, manifest e IAM. I valori infrastrutturali restano vincolati dal contratto generato da Terraform.

Il publisher prova il binario con --check-config in un container senza rete; packaging e release confrontano sorgenti e render con i requisiti. Serve mantenere la stessa validazione nella modalità di controllo e nell'avvio normale. Questo non sostituisce il collaudo dei permessi effettivi o delle API. Farm è il primo componente che adotta il controllo; Access conserva il contratto precedente finché non viene esplicitamente aggiornato.

Profili ed esempi

Profilo delivery	Limite attuale
service-with-migration	Un backend SQL più un migratore separato: provato con Access e Farm; riusabile per altri sistemi con questa combinazione.
service	Service senza SQL; provato con la fixture recovery. Ogni nuovo componente verifica i propri grant e comportamento.
service-read-only	Service SQL readonly con baseline dedicata; prove cloud aggiuntive mancanti.
job	Job finito senza SQL; esecuzione e scheduling richiedono prove distinte.
service-runtime-sql	Relay, consumer o sweeper che scrive con il proprio ruolo <sistema>_<componente>, senza migratore né DDL. Disponibile dall'11 novembre; primo collaudo con i rilasci dopo il reset dello stage.
job-runtime-sql	Job operativo con il proprio ruolo SQL, es. access-bootstrap-admin. La pipeline lo rilascia ma non lo esegue: lo eseguono solo gli infra-admins e ogni esecuzione genera un allarme.

Componente SQL aggiuntivo sullo stesso schema: usa service-runtime-sql o job-runtime-sql, con una delivery propria e il proprio ruolo SQL creato da infra nel baseline v3. Il migratore del sistema resta unico; il componente controlla all'avvio lo schema che gli serve e si rilascia dopo la migrazione da cui dipende. Dettaglio.

I profili build sono rust-system, rust-library, dependency e rust-slint-app; nuxt-app per l'app Account è proposto e non ancora unito. Non coprono automaticamente qualsiasi linguaggio.

Access, esempio reale: access-backend, Platform stage, DB access, runtime sa-accounts; access-migrate usa sa-access-migrate. Build/delivery, kit e rilasci sono collaudati; nuovi controlli della CLI hanno test separati e non cambiano retroattivamente quelle ricevute.

Job, esempio illustrativo non registrato: un controllo finito legge un bucket autorizzato, senza SQL. Vanno definiti identità, oggetti leggibili, durata/retry ed esito; aggiungere Scheduler soltanto se serve. Non assegnargli ora nomi cloud o permessi inventati.

Seguono stato e prossimi passi, collaudi e fonti.