Review delle evidenze di Deployment di un catalogo Terraform
Reply CMP Blog - ARTICOLO 2 (Settembre 2026)
Un primo Apply completato con successo può nascondere il rischio più grande in un catalogo self-service: il platform team potrebbe promuovere un percorso che ha funzionato una sola volta, in condizioni di cui nessuno ha ancora dimostrato la ripetibilità.
Una business unit chiede di distribuire un catalog item “standard environment” a diversi product team. Il pilot fornisce al platform team due segnali: un deployment Azure è stato applicato con successo, mentre un altro è stato bloccato prima del Plan perché il Deployment non era pronto.
La risposta più semplice sarebbe: “Il modulo funziona. Sistemiamo quello bloccato e rendiamo disponibile il catalog item.”
La risposta più sicura è: “Non ancora. Prima dobbiamo dimostrare che il deployment path sia ripetibile.”
Un Apply completato dimostra che qualcosa è stato eseguito. Non dimostra che la risorsa richiesta, il module path, il runner, lo state, le credenziali, i permessi, il policy gate, il provider scope e le execution evidence siano adatti a un utilizzo self-service.
Il completamento non è il punto di controllo
Il self-service provisioning è un operating contract, non semplicemente un'esecuzione Terraform.
Il consumer si aspetta un percorso governato attraverso cui richiedere un pattern noto. Il platform team si aspetta che la richiesta utilizzi codice approvato, credenziali controllate, policy check ed execution evidence verificabili. I team Finance e Security si aspettano che il risultato venga distribuito nello scope corretto, con un livello sufficiente di informazioni su ownership e controlli da consentirne la gestione successiva.
Per questo motivo, un semplice “green” è un criterio troppo debole per decidere una promotion. Un catalog item può completare correttamente l'Apply semplicemente perché un operatore esperto ha scelto i valori corretti, un runner era già configurato, uno state container era raggiungibile oppure una cloud connection disponeva di privilegi più ampi rispetto a quelli che dovrebbe avere il percorso self-service previsto.
Anche un'esecuzione fallita o bloccata può fornire informazioni altrettanto utili. Un readiness block non è un difetto del modulo. Un policy block può indicare che la guardrail sta funzionando correttamente. Un errore relativo ai permessi del provider può invece evidenziare che il catalog path non è ancora stato testato utilizzando l'access model previsto per gli utenti standard.
Analizzare il percorso, non soltanto l'esecuzione
Dopo un Plan, un Apply, un errore o un blocco, la prima domanda dovrebbe essere:
Siamo in grado di spiegare con sufficiente chiarezza cosa è successo per decidere se questo catalog item debba essere promosso, corretto, ritestato oppure mantenuto non disponibile?
Per la richiesta di rollout, confrontiamo l'Apply completato con successo e il deployment bloccato utilizzando lo stesso evidence model. Se entrambi utilizzavano lo stesso module record, repository path e provider scope previsto, il blocco potrebbe indicare semplicemente un problema di setup da risolvere. Se invece utilizzavano path, credenziali o cloud scope differenti, il team non dispone ancora di un unico pattern ripetibile. Ha invece due eventi distinti che richiedono review separate.
Una review delle evidenze in sette punti
Utilizza questa checklist prima di considerare un catalog item basato su Terraform pronto per un utilizzo self-service più ampio.
1. Request e module record
Registra ciò che è stato richiesto: environment type, target provider, input necessari e resource pattern previsto. Collega quindi la richiesta al module record e al repository path utilizzati.
Non utilizzare un'esecuzione riuscita su un determinato Terraform path come evidenza per un diverso catalog route.
2. Stato del runner
Il runner è parte integrante dell'evidence chain. Verifica quale customer-owned runner ha gestito l'operazione, se fosse pronto prima del Plan o dell'Apply e se abbia restituito status ed evidence.
Se un deployment è stato bloccato prima dell'esecuzione perché il runner non era pronto, classificalo come readiness evidence, non come un errore Terraform.
3. Protected state
Il Terraform state dimostra la continuità tra le diverse esecuzioni. Verifica dove è configurato lo state, se i relativi accessi siano appropriati e se il deployment path sia in grado di leggere, scrivere e acquisire il lease dello state quando necessario.
Nel provisioning di Reply CMP, ogni Deployment richiede un customer-owned runner e una protected Azure Blob state location. Plan e Apply vengono bloccati finché runner e state non sono pronti, rendendo così visibile la readiness del setup durante la review.
4. Scopo delle credenziali
Non ridurre la verifica delle credenziali a un semplice “l'accesso ha funzionato”. Distingui la dispatch credential dalle cloud connection.
La dispatch credential avvia la pipeline Azure DevOps o il workflow GitHub configurato. Le cloud connection collegate al Deployment vengono invece utilizzate dai Terraform provider e dallo state. Questa distinzione consente di rispondere a domande di controllo differenti: cosa ha avviato il workflow, quali risorse Terraform poteva gestire e quale connection è stata utilizzata per lo state.
5. Permessi e policy gate
Policy e permessi fanno parte della ripetibilità del processo. Verifica che requester e reviewer previsti dispongano dei permessi Reply CMP necessari per moduli, credenziali e Deployment. Verifica inoltre che la cloud connection disponga dei provider permission necessari per gestire le risorse target e lo state.
Controlla infine il risultato della policy. Un deployment che funziona soltanto per gli administrator potrebbe non essere pronto per gli utenti a cui è realmente destinato.
6. Provider scope
Un modello di review comune non rende Azure, AWS e GCP intercambiabili.
Conferma esplicitamente il target provider. Module input, provider alias, permessi, state expectation e operating assumption possono variare in base al provider. Le evidenze provenienti da un deployment Azure non dovrebbero essere utilizzate come prova che lo stesso catalog path sia pronto anche per AWS o GCP, a meno che le relative assunzioni provider-specific non siano state analizzate.
7. Execution evidence
Infine, analizza le evidenze dell'esecuzione: Plan status, Apply status, failure message, status riportato dal runner, policy result e troubleshooting classification.
Un record utile non dovrebbe limitarsi a indicare “success” o “failed”. Dovrebbe invece rappresentare un vero e proprio decision trail:
Standard environment richiesto; module path confermato; runner pronto; protected state configurato; la dispatch credential ha avviato il workflow; provider connection e state connection confermate; policy superata; Apply evidence disponibile; procedere con la promotion applicando i normali controlli.
Oppure:
Standard environment richiesto; module path confermato; Plan bloccato perché runner e state non erano pronti; nessuna Terraform evidence disponibile; correggere il setup del Deployment ed eseguire nuovamente il test prima della promotion.
Dove si inserisce Reply CMP
Reply CMP supporta il governed provisioning attraverso risorse soggette a policy gate, moduli basati su Terraform, customer-owned runner e configurazione del protected state.
Il provisioning setup documentato utilizza un repository GitHub o Azure DevOps per i file del runner, una subscription Azure con uno Storage account esistente e un Blob container privato per il Terraform state, una Azure Connection read-write attiva in grado di gestire le risorse target e accedere agli state blob, oltre ai permessi Reply CMP necessari per gestire provisioning module, credenziali e Deployment.
All'interno di ogni Deployment, la vista Runner & state mostra il runner, il callback trust e la Azure Connection utilizzata per lo state. Reply CMP blocca Plan e Apply finché runner e state non risultano pronti. Inoltre, mantiene separati gli scopi delle credenziali: le dispatch credential avviano la pipeline o il workflow configurato, mentre le cloud connection collegate al Deployment vengono utilizzate dai Terraform provider e dallo state.
Questo non automatizza il processo decisionale. Fornisce ai reviewer i control point necessari per stabilire se un catalog route sia sufficientemente ripetibile per il self-service.
Decidere in base alla classe di evidenza
Le evidenze devono comunque essere interpretate. Una policy può essere troppo restrittiva o troppo permissiva. Può mancare una role assignment. Un modulo può funzionare in una subscription e fallire in un'altra perché è cambiato il provider scope. La buona pratica consiste nel classificare l'evidenza prima di intervenire.
Promuovere per il self-service
Evidenze
Request, module path, runner, state, credenziali, permessi, policy, provider scope ed execution evidence sono coerenti.
Azione successiva
Pubblicare o ampliare la disponibilità mantenendo i normali controlli di review.
Correggere ed eseguire nuovamente
Evidenze
Il module path è valido, ma runner, state, input o execution evidence sono incompleti.
Azione successiva
Correggere il setup o gli input, quindi eseguire nuovamente Plan o Apply.
Correggere permessi o policy
Evidenze
Le evidenze indicano un platform permission mancante, un cloud role non corretto, problemi di accesso allo state o un policy mismatch.
Azione successiva
Correggere accessi o policy, quindi eseguire nuovamente il test con gli utenti previsti.
Mantenere il catalog item non disponibile
Evidenze
Il provider scope non è chiaro, le credenziali hanno uno scopo errato o privilegi eccessivi, oppure i reviewer non riescono a dimostrare cosa sia stato eseguito.
Azione successiva
Mantenere il catalog item non disponibile finché il control record non risulta verificabile.
I cataloghi self-service scalano quando i team possono fidarsi del percorso, non soltanto dell'ultima esecuzione. Un Apply completato con successo è un'evidenza. Non rappresenta l'intera review.