Il processo di deploy che funzionava con 5 ingegneri si rompe con 15
Ogni team di ingegneria, a un certo punto, esegue deploy manuali, e per un po' va tutto bene. Una o due persone conoscono i passaggi, la checklist vive in un documento Notion, e i rilasci avvengono quando qualcuno ha un pomeriggio libero. Poi il team cresce oltre i 15 ingegneri, la frequenza dei rilasci passa da settimanale a giornaliera, e lo stesso identico processo inizia a produrre incidenti.
Vediamo continuamente questo schema: un team che ha rilasciato in sicurezza per due anni ha improvvisamente un mese pessimo. Non perché qualcuno sia diventato peggiore nel proprio lavoro — perché il processo non è mai stato scalato oltre l'organico per cui era stato pensato. I deploy manuali sono un sistema a singolo punto di guasto travestito da "è così che abbiamo sempre fatto".
La domanda che ci viene posta non è "dovremmo automatizzare?" Su questo sono già tutti d'accordo. La domanda è cosa automatizzare per primo, perché i team che cercano di sistemare tutto in uno sprint di solito si arenano e non rilasciano nulla. Ecco l'ordine che funziona davvero, basato sullo schema che osserviamo nei team in fase di crescita.
Sistema il percorso di deploy prima di toccare l'infrastruttura
L'istinto, quando le cose sembrano fragili, è puntare prima sull'infrastructure-as-code — mettere tutto su Terraform, portare i server sotto controllo. È la mossa sbagliata da fare per prima. Se il tuo processo di deploy è ancora "fai SSH e lancia uno script", trasformare in Terraform la macchina su cui gira non risolve il vero problema: una persona che esegue a mano un compito ripetibile, sotto pressione di tempo, senza un piano di rollback.
Il primo dollaro investito in automazione dovrebbe andare al CI/CD: una pipeline che gira a ogni push, esegue sempre gli stessi test e distribuisce sempre nello stesso modo. Concretamente, questo significa:
- Ogni merge su main attiva una build e una suite di test — nessuna eccezione, nessun push manuale "solo per questa volta".
- Il passaggio di deploy è un job della pipeline, non il terminale di una persona. GitHub Actions, GitLab CI o CircleCI gestiscono tutti questo compito; lo strumento conta meno della disciplina di usarlo sempre.
- Il rollback è un pulsante, non una persona che alle 23 cerca di ricordare l'hash dell'ultimo commit funzionante.
I team che fanno questo per primi vedono in genere un calo evidente degli incidenti legati al deploy già nel primo mese, senza toccare un solo file Terraform. Il motivo: la maggior parte degli incidenti "infrastrutturali" in questa fase non sono problemi di infrastruttura. Sono problemi di processo travestiti da infrastruttura — un valore di configurazione che esiste solo nella testa di un ingegnere, un passaggio di migrazione che qualcuno ha dimenticato di eseguire, un deploy avvenuto fuori ordine rispetto a un altro.
Poi rendi gli ambienti riproducibili
Una volta automatizzati i deploy, emerge il prossimo problema: "funziona in staging ma non in produzione", o peggio, "non ricordiamo più come era configurato lo staging". È qui che l'infrastructure-as-code si guadagna il suo posto — non come prima soluzione, ma come seconda.
I moduli Terraform o OpenTofu che descrivono il tuo ambiente AWS, GCP o Azure come codice versionato risolvono un problema specifico: il drift degli ambienti. Senza IaC, ogni ambiente accumula piccole differenze non documentate — qui una dimensione di istanza modificata a mano, là una regola di security group aggiunta durante un incidente — finché lo staging smette di essere un predittore affidabile del comportamento in produzione.
L'obiettivo pratico non è "automatizzare il 100% dell'infrastruttura" dal primo giorno. È: riesci a distruggere e ricostruire il tuo ambiente di staging da codice in meno di un'ora, senza bisogno di conoscenza tribale? Se la risposta è no, è quello il prossimo problema da risolvere — prima di Kubernetes, prima del multi-region, prima di qualsiasi cosa più ambiziosa.
Gli ambienti di preview chiudono il cerchio aperto dal CI/CD
Con i deploy automatizzati e l'infrastruttura riproducibile, la leva successiva è dare a ogni pull request il proprio ambiente usa e getta. È il passaggio che i team saltano perché sembra un lusso, ma di solito è l'automazione con il ritorno più alto dopo le prime due.
Senza ambienti di preview, alla domanda "funziona davvero?" si risponde in staging, che è condiviso, il che significa che le modifiche di ogni ingegnere entrano in collisione con quelle di tutti gli altri. Il QA diventa una coda. I bug vengono trovati tardi, dopo che più modifiche si sono accumulate una sull'altra, il che li rende costosi da isolare. Gli ambienti di preview — creati per ogni PR e smantellati al merge — trasformano quella coda di nuovo in test paralleli e indipendenti. I team che li introducono dopo aver sistemato la pipeline di deploy vedono in genere migliorare il tempo tra review e merge, perché i revisori possono cliccare su un link e vedere la modifica reale in esecuzione invece di leggere un diff e fidarsi.
Cosa automatizzare per ultimo, non per primo
Il progressive delivery — canary release, feature flag, rollback automatico sui picchi di error rate — è reale e utile, ma è un investimento da fase successiva. Risolve il problema di "come distribuire in sicurezza al traffico di produzione", che conta solo una volta che il rilascio in produzione è già di per sé affidabile e noioso. I team che costruiscono l'infrastruttura per i canary prima di avere un CI/CD funzionante stanno automatizzando il rischio sbagliato; la logica di traffic-shaping non serve a nulla se il deploy sottostante dipende ancora da qualcuno che esegue i comandi giusti nell'ordine giusto.
Kubernetes rientra nella stessa categoria tardiva per la maggior parte dei team in crescita. Risolve problemi reali — autoscaling, isolamento delle risorse, servizi self-healing — ma aggiunge una vera e propria superficie operativa: manifest, Helm chart, aggiornamenti del cluster, RBAC. I team sotto i 20 ingegneri circa, che gestiscono una manciata di servizi, sono di solito meglio serviti da una piattaforma più semplice (ECS, Cloud Run, un PaaS gestito) con un CI/CD solido davanti. Passa a Kubernetes quando hai abbastanza servizi da rendere reale il problema dell'orchestrazione, non perché è il passo successivo previsto.
Una sequenza realistica, e quanto costa
Per un team di 15-25 ingegneri che esce da deploy manuali o semi-manuali, una sequenza come questa di solito funziona: prima una pipeline CI/CD con test automatizzati e rollback a un clic (tipicamente 2–4 settimane), poi l'infrastructure-as-code per gli ambienti principali (altre 3–5 settimane, a seconda di quanto drift si sia già accumulato), poi ambienti di preview e monitoraggio/alerting sopra il resto. Una configurazione CI/CD da sola parte tipicamente da $8,000; la sequenza completa — CI/CD più infrastructure-as-code più ambienti di preview — parte tipicamente da $25,000+ a seconda di quanti servizi e ambienti rientrano nel perimetro — ed è un roll-out a fasi che il nostro team cloud & DevOps pianifica fase per fase, invece che come un'unica ricostruzione della piattaforma senza fine.
L'errore da evitare è trattare tutto questo come un unico grande progetto infrastrutturale con una sola data di lancio. Ogni fase dovrebbe essere rilasciata in autonomia e iniziare a ripagarsi da subito — una pipeline CI/CD funzionante ha valore di per sé, anche prima che esista Terraform a sostenerla.
In sintesi
Quando i deploy manuali iniziano a rompersi, la soluzione non è "procurarsi più strumenti DevOps". È la sequenza: prima la pipeline, poi l'infrastruttura riproducibile, poi gli ambienti di preview, e solo alla fine progressive delivery e orchestrazione, quando le basi sono ormai noiose. I team che automatizzano in questo ordine risolvono i loro incidenti peggiori entro il primo mese. I team che partono dallo strumento più sofisticato della lista di solito passano un trimestre a costruire infrastruttura per un processo di deploy che, sotto sotto, resta fondamentalmente manuale.
