06 - Collaudi
Guida iniziale · Sequenza di lavoro
I test verificano il meccanismo comune, poi l'integrazione del servizio. Usiamo Access, il backend+migratore Farm già sviluppati e fixture isolate per i guasti. Validazioni, digest e casi unitari si provano localmente; IAM, rete, Cloud SQL e trigger richiedono verifiche cloud rappresentative. Un apply riuscito non dimostra da solo il funzionamento.
Sono ammessi primi deploy controllati con fixture isolate per accettare nuovi profili. Prima del collaudo il profilo non è disponibile per l'uso ordinario: questo non impedisce la prova necessaria a renderlo disponibile.
Checklist della consegna iniziale¶
| Area | Test e risultato richiesto |
|---|---|
| Modello | Esempi validi accettati; identità, risorse o capability incoerenti rifiutate. Distinguere profilo disponibile da esempio solo documentale. |
| Rilascio Access | Nuova build sullo SHA ammesso → preparazione → approvazione Deploy → migrazione → backend Ready. Ritrovare un rollout già riuscito non vale come nuovo test. |
| Operatori | Una prova completa del flusso comune; ogni persona verifica le proprie azioni nel normale primo uso. Nessuna sessione dedicata di Lorenzo è un prerequisito. Grant personali ampi vanno distinti dalla sufficienza dei soli gruppi. |
| Ripresa e recupero | Interrompere la CLI senza duplicare build; riconciliare un avvio ambiguo. Prima del retry leggere Operation/Execution precedente: se attiva o incerta, non lanciarne un'altra. Provare il recupero su fixture, senza ignorare migrazioni fallite. |
| Ordine dei rilasci | Test automatici del comando di approvazione: stesso target/pipeline, candidato corretto, snapshot recente e invariato, rifiuto di rollout attivi/incerti o più nuovi non scartati. Ispezione prima del normale uso; accordo del team resta necessario, perché controllo e POST non sono atomici e la console resta un altro canale. Nessuna necessità di rompere nuovamente lo stage. |
| Prima creazione | Workload nuovo o creato ma non Ready: grant nominali applicati, finestra IAM chiusa, contratti aggiornati e recupero tracciato. |
| SQL iniziale | Runtime limitato ai dati autorizzati: niente DDL, ownership o assunzione del ruolo migratore. Migratore separato: applica le mancanti, no-op se già presenti, errore blocca il nuovo backend; compatibilità con la revisione precedente. Provare inoltre il rifiuto di una migrazione applicata sconosciuta al codice, senza modificare il ledger. Riusare le prove valide; integrare quelle mancanti. |
| S2S e risorse | Dopo il primo rilascio dello skeleton Farm, un Job sonda in Platform prova il percorso Shared VPC verso il backend: chiamata autorizzata riuscita, identità/audience errate negate. Configurare e verificare separatamente l'autorizzazione dell'operazione Catalog se scelta. Le prove SQL precedono il rilascio; un errore DNS non prova un diniego IAM. |
| Operatività | Traccia/metrica nuova, allarme ricevuto, limiti SQL/istanze e spesa controllati; un restore rappresentativo su copia isolata. Usare il percorso v1 di 02: fix/revert compatibile su main, migrazioni preservate e normali gate; test di compatibilità e del migratore. Il retry non vale come prova di rollback. Non ripetere il restore per ogni nuova API. |
Il collaudo S2S usa private-ranges-only, DNS privato run.app già applicato e Private Google Access, con le revisioni destinatarie collegate alla Shared VPC. La prova precedente ALL_TRAFFIC o una chiamata solo dentro Platform non coprono questa configurazione. Conservare URL run.app e audience coerenti; registrare risoluzione DNS, identità ed esiti positivi/negativi. Il destinatario è il backend Farm reale; soltanto la sonda Platform e il suo grant sono temporanei. Non occorrono Console o le ulteriori funzionalità Farm. Procedura della sonda · Requisiti Google per la Shared VPC.
Estensioni da accettare quando richieste¶
- Eventi e Job: push autenticato, duplicati, retry, ack durevole e dead-letter; Job con Execution ID, completamento/fallimento e doppia invocazione. L'avvio accettato da Scheduler non prova il risultato. L'uso di un Job sonda non certifica la schedulazione applicativa.
- Readonly: il runner SQL prova i privilegi senza Dev ORM, ma non la delivery
service-read-only; per accettare quest'ultima serve anche un Service di prova.
Queste prove non bloccano i profili API già accettati. I workload e i grant temporanei delle fixture vengono rimossi; le definizioni e gli artefatti protetti possono restare inattivi per audit, senza indebolire le protezioni contro la cancellazione.
Prima di attivare ulteriori componenti sullo stesso schema¶
Queste prove accettano la futura estensione della delivery SQL; non bloccano la consegna del percorso backend + migratore:
- Due identità runtime possono scrivere i dati concessi; entrambe restano senza DDL o accesso allo schema di un altro sistema.
- Il nuovo componente resta bloccato se manca lo schema compatibile richiesto; dopo il successo del migratore può essere distribuito senza una propria migrazione indipendente.
- Estendere le prove di ordinamento già previste nella base iniziale alla delivery di più componenti: due tentativi di migrazione non applicano la stessa modifica in concorrenza. Il lock delle migrazioni non sostituisce transazioni e idempotenza delle scritture applicative.
- Una patch compatibile aggiorna un solo componente. Durante un cambiamento di schema le versioni ancora attive restano funzionanti.
- Un errore di migrazione blocca i dipendenti; un errore successivo del consumer si recupera per componente, senza presumere un rollback globale o distruttivo dello schema.
Usare fixture isolate e registrare quale profilo è stato accettato. La correttezza delle operazioni concorrenti sui dati richiede anche i test applicativi del sistema.
Prove già disponibili e limiti¶
Farm, 10 novembre: publisher riuscito, DNS privato applicato e riletto, baseline SQL applicata e riletta; metadati della fixture precedente e catalogo Access invariati, credenziali/risorse amministrative temporanee rimosse. Rollout e migrazioni riusciti; identità SQL verificate prima e dopo, con sei database estranei negati a entrambe e runtime senza DDL/ledger. Finestra IAM chiusa. Cinque casi S2S e cleanup riusciti; metriche e una traccia correlata ricevute. La seconda traccia richiesta non è stata osservata. No-op del migratore verificato con l'identità operatore: non equivale a un nuovo rollout Cloud Deploy dopo la chiusura IAM. Le righe della vecchia fixture non sono state lette o certificate. Stato e ricevute Farm.
La prova del 7 novembre comprendeva rollout, migrazione no-op e 360 richieste private health/ready, con tracce e metriche. Il nuovo collaudo del 9 novembre, distinto da quella prova, è riassunto sotto. I casi migrazioni mancanti/errore hanno prove locali dedicate. Questo non prova login staff, tutti gli endpoint o carico di cento allevamenti.
L'estensione kit/recupero di infra d5904b ha superato 82 test Python, più 63 test bootstrap e 93 stage. Le sei aggiunte IAM sono applicate, i piani successivi non mostrano differenze e il kit reale Access è verificato. Il nuovo flusso cloud ha completato pubblicazione, preparazione e rollout con migrazione prima del backend. Un nuovo processo operatore ha ritrovato lo stesso publisher senza crearne un altro. La nuova sonda ha completato 360 richieste HTTP 200; sono ricevute nuove tracce, metriche applicative e metriche SQL proxy. Risorse e grant temporanei sono rimossi. Risultati e ricevute del 9 novembre.
Il recupero ha letto gli stati reali e rifiutato retry non ammessi. La successiva fixture SQL-free ha provato il retry reale dello stesso job/candidato dopo un errore di permesso: nuovo JobRun riuscito, errore originale conservato, richiesta duplicata rifiutata e 10 risposte HTTP 200 prima, durante e dopo il guasto. Pulizia completata e piani finali senza differenze. Non prova recupero di migrazioni SQL, routing Platform→Farm o concorrenza fra operatori. La riconciliazione resta assistita; Lorenzo verifica le proprie azioni al normale primo uso, senza un collaudo duplicato come prerequisito.
I test dei guasti restano isolati; non inseriamo deliberatamente una migrazione errata nel servizio condiviso. Il recupero applicativo non annulla lo schema: serve compatibilità. Le code hanno retention finita anche a push sospeso; il test deve prevedere replay e cleanup, senza perdere backlog reale.
Evidenze e chiusura¶
Per ciascuna prova salvare commit, hash dei contratti, identità, build/release/rollout o Execution ID, digest, orari, risultato e log sanitizzati. Registrare costi/risorse temporanee e relativa chiusura.
La prova comune verifica il profilo; ogni nuovo componente verifica i propri grant, configurazione e prima release. RPC, isolamento tra aziende e correttezza dei dati sono test applicativi. Si riusano le evidenze compatibili: la batteria comune si ripete quando cambia il meccanismo interessato, non per ogni servizio.
La consegna iniziale si chiude con i punti 1–4 della scheda 05. Le estensioni sono accettate separatamente, quando richieste, e restano esplicitamente aperte. Lo sviluppo può procedere prima; i rilasci ordinari usano profili già accettati. Web staff/clienti avranno test propri prima dell'apertura.
Le soglie iniziali, RPO/RTO proposti e la prova isolata sono nella scheda 12. Non sono nuovi allarmi applicati o un restore già eseguito.