Sostituisca «speriamo che funzioni»
con git push origin main.
Container, pipeline CI/CD, Kubernetes, infrastructure as code (IaC), osservabilità e automazione dei rilasci — tutto da un unico team. Lo sviluppatore esegue «git push»; lint, test, build, scansione di sicurezza, push dell'immagine e rilascio avvengono in automatico in pochi minuti. Se qualcosa va storto, il rollback avviene in 18 secondi. Secondo gli standard DevOps tedeschi.
L'unico modo per far sì che un rilascio smetta di essere un «evento» è un'automazione disciplinata. Se vuole smettere di fare i turni del venerdì notte, è nel posto giusto.
I rilasci «speriamo che funzioni» stanno logorando il suo team.
Parliamo onestamente dei numeri: un rilascio fallito non è solo una perdita di fatturato — è una perdita di fiducia all'interno del team. Ecco i cinque problemi più comuni che riscontriamo.
Se una persona si collega al server via SSH, scarica i file e riavvia i servizi, quel rilascio si mangia mezza giornata lavorativa. Se salta un passaggio, ce ne si accorge il lunedì. Il rilascio programmato per il venerdì sera slitta fino a mezzanotte; l'ingegnere DevOps che quella sera doveva essere libero, in realtà, non lo è. A fine mese questo circolo produce burnout, a fine trimestre dimissioni. La soluzione: a premere il pulsante di rilascio deve essere la pipeline, non una persona.
Se dopo un rilascio compare un errore, l'approccio «git revert + nuovo rilascio» richiede ore, non minuti. In quelle ore i pagamenti non passano, le registrazioni non vanno a buon fine e il call center viene sommerso dalle chiamate. In una pipeline ben fatta il rollback è un pulsante — l'immagine precedente è ancora nel registry, il Deployment Kubernetes torna alla revisione precedente e in 18 secondi tutto è come prima. Per il rollback non serve un «piano», serve un meccanismo.
Senza una pipeline CI i test non vengono eseguiti — perché «adesso abbiamo fretta». Ogni piccolo bug che emerge in produzione si accumula internamente, perché al cliente non viene mai comunicato. A un certo punto gli sviluppatori smettono di scrivere codice e iniziano a rispondere ai ticket di assistenza. La soluzione: a ogni commit partono in automatico l'intera suite di test, l'analisi statica, il type check e la scansione di sicurezza. Il codice che non supera questi controlli non viene mai integrato in main.
Sei mesi fa qualcuno ha modificato una configurazione nginx sul server di produzione. Quella persona non lavora più in azienda. Nessuno ricorda la modifica. Quando si configura un nuovo server, lo stesso comportamento non è più riproducibile. L'infrastructure as code (IaC) risolve il problema: Terraform, Pulumi, chart Helm, manifest Kubernetes — tutto vive in git. Elimini un server e ne ricostruisca uno identico in 8 minuti.
Il sistema è andato giù sabato alle 3:14. Nessun avviso su Slack, solo un cliente che lunedì mattina dice «non si apre». Servono 4 ore per trovare i log e 3 per capire la causa. Il vero DevOps è questo: un alert di Prometheus la sveglia sabato alle 3:14, la causa è visibile sulla dashboard Grafana, si esegue il runbook e in 12 minuti il problema è risolto. Il fine settimana resta un fine settimana.
Una produzione che si ripara da sola e migliora di continuo.
Dall'auto-healing dei pod Kubernetes all'IaC con Terraform, dalle metriche DORA al rollback con un clic — ecco come si presenta davvero l'operatività quotidiana.
> pod web-7d4 pronto in 2,1 s — il servizio continua
resource "aws_eks_cluster" "prod" {
name = "partnerfy-prod"
version = "1.29"
role_arn = aws_iam_role.eks.arn
vpc_config {
subnet_ids = aws_subnet.priv[*].id
}
}
Plan: 14 to add, 0 to change, 0 to destroy.
Apply complete! Resources: 14 added.
I quattro indicatori chiave dello stato di salute della produzione
Torni alla revisione precedente
kubectl rollout undo deployment/web
Per quali team fa la differenza?
Da anni implementiamo DevOps in settori diversi. Questi otto profili sono i team che ottengono da noi il massimo valore.
SaaS con rilasci quotidiani
Richiesta del cliente → branch → review → in produzione in 30 minuti. Da 5 a 15 rilasci al giorno dovrebbero essere la normalità.
E-commerce con frequenti test A/B
Feature flag che portano una variante sul 5% del traffico, metriche confrontate in automatico, la vincente viene attivata da sola.
Fintech regolamentate
Catena di approvazione, audit log, build immutabili, separazione dei compiti. Pipeline pronta per SOC2 e PCI.
B2B multi-tenant
Ambiente per cliente, rollout graduale, feature flag per tenant, monitoraggio SLA per cliente.
CD su TestFlight / Play
Fastlane + Bitrise + automazione della firma. Ogni PR genera in automatico IPA/AAB e li distribuisce ai dispositivi di test.
Startup in migrazione dal monolite ai servizi
Pattern strangler fig, service mesh (Istio/Linkerd), passaggio graduale. I due mondi funzionano in parallelo.
Grande azienda che modernizza i sistemi legacy
Containerizzazione delle VM on-premise, migrazione del vecchio Jenkins a GitOps e di Active Directory a OIDC.
Agenzia con oltre 20 repository di clienti
Template di pipeline, repo-of-repos, gestione centralizzata dei secret. Nuovo cliente = in produzione in 2 ore.
I dieci livelli di uno stack DevOps.
A ogni livello scegliamo lo strumento più adatto — invece di imporre una tecnologia, cerchiamo l'equilibrio tra le abitudini del team e la sostenibilità a lungo termine.
Containerizzazione
L'applicazione viene inserita in un Dockerfile, le build multi-stage producono immagini minime che vengono inviate in automatico al registry. La stessa immagine attraversa dev → staging → prod.
Pipeline CI
A ogni commit: lint, test unitari e di integrazione, analisi statica, scansione di sicurezza, build dell'immagine. Il codice che non supera i controlli non viene integrato.
Pipeline CD
Approccio GitOps: i manifest in git sono l'unica fonte di verità. ArgoCD sincronizza di continuo; in caso di drift corregge subito o invia un alert.
Configurazione di Kubernetes
Gestito (EKS/GKE/AKS) o self-hosted (k3s, kubeadm). Dimensionamento del cluster, node pool, autoscaling e network policy vengono progettati insieme.
Chart Helm
L'applicazione viene impacchettata in un chart parametrico — con file di valori diversi per staging e prod. Aggiornare la versione richiede un solo comando.
IaC con Terraform / Pulumi
Le risorse cloud (VPC, RDS, S3, IAM) sono definite come codice. Ciclo plan → review → apply, stato remoto e bloccato, rilevamento del drift.
Gestione dei secret
I file .env a rischio di fuga di dati diventano un ricordo. Cifrati con Vault o SOPS — la pipeline li recupera dinamicamente a runtime, lo sviluppatore non li vede mai.
Osservabilità
Metriche (Prometheus) + log (Loki) + trace (Tempo) + dashboard (Grafana). Alert basati sugli SLO e monitoraggio dell'error budget.
Reperibilità e alert
Quale alert sveglia chi? Turni, escalation, alert collegati ai runbook. Basta svegliare la persona sbagliata alle 3 del mattino.
Scansione di sicurezza
Una CVE nell'immagine? Una vulnerabilità critica in una dipendenza? La pipeline ferma la build e propone una correzione automatica nella PR. Sicurezza shift-left.
Dalla vecchia pipeline a quella moderna in sei passi.
Non cambiamo tutta l'infrastruttura da un giorno all'altro. Procediamo per fasi, senza interrompere il business e coinvolgendo il suo team.
Audit della pipeline attuale
Sprint di 2 settimane: come rilascia oggi, quali passaggi sono manuali, quale servizio è un single point of failure, dove sono conservati i secret.
Containerizzare le applicazioni
Ogni servizio riceve un Dockerfile, viene alleggerito con build multi-stage e inviato al registry. Dev e prod usano lo stesso pacchetto.
Realizzare la pipeline CI
Lint, test, build e scansione automatizzati. All'apertura di una pull request, il bot restituisce verde o rosso in 6-8 minuti.
Realizzare la pipeline CD
GitOps con ArgoCD o Flux: staging automatico a ogni merge, prod con una sola approvazione. Canary e rollback pronti.
Collegare l'osservabilità
Prometheus + Grafana + Loki. Si definiscono gli SLO, si collegano le regole di alert ai runbook e si organizza la rotazione della reperibilità.
Formare il team e passare le consegne
Workshop di 2 giorni + documentazione + set di runbook. Nei 3 mesi successivi, supporto discreto: risposte alle sue domande entro un'ora.
Le tecnologie che usiamo in produzione.
Prima / dopo — in numeri.
Jenkins → GitHub Actions + ArgoCD. Dal merge alla produzione in 12 minuti. Fine della paura dei rilasci del venerdì sera.
Prometheus + PagerDuty + automazione dei runbook. L'alert parte prima del down, arriva alla persona giusta e include i passaggi per risolvere.
Build immutabili, separazione dei compiti, audit trail completo, secret cifrati. Pronti per l'audit in 6 mesi, nessun rilievo da parte dell'auditor.
Rolling update + readiness probe + canary release. In 6 mesi nemmeno un'interruzione visibile ai clienti.
Fastlane + Bitrise + automazione della firma. Il team QA vede la nuova build sul dispositivo 4 minuti dopo ogni PR.
Workflow GitHub Actions riutilizzabile + CLI di bootstrap. Il nuovo cliente apre un repository ed è in produzione in 2 ore.
Cosa ci chiedono più spesso
In breve: no. Se la sua scala è ridotta (1-3 server in una sola regione, meno di 20.000 richieste/min), opzioni come Docker Compose, AWS ECS Fargate, GCP Cloud Run, Fly.io o Render comportano un carico operativo molto inferiore. Il vero valore di Kubernetes emerge quando servono più di 5 servizi, più regioni, autoscaling, strategie di rollout avanzate (canary/blue-green) e un mesh tra i servizi. La decisione si prende insieme durante l'audit; non la spingeremo a «seguire la moda». Se si passa a K8s, consigliamo una soluzione gestita (EKS/GKE/AKS) — non dovrà amministrare un suo cluster.
Di solito no, almeno non subito. Se Jenkins funziona, costruiamo la nuova pipeline in parallelo (GitHub Actions / GitLab CI / Drone). I nuovi servizi passano dalla nuova pipeline, quelli esistenti restano su Jenkins. Le due soluzioni convivono per 2-3 mesi e, quando il team si è abituato, la migrazione viene completata. L'approccio «butta via tutto e riscrivi da zero» richiede 6 mesi e lascia tutto a metà. La nostra esperienza: la strategia strangler fig dà sempre risultati migliori. Se Jenkins non è davvero manutenibile (versione datata, esplosione di plugin, nessuno lo capisce) — glielo diremo con franchezza.
Calendario tipico: CI/CD di base (container + test + build + rilascio) 2-4 settimane. Aggiunta di Helm + Kubernetes +2-4 settimane. Osservabilità completa (Prometheus + Grafana + Loki + alert) +2-3 settimane. Gestione del cloud con Terraform/IaC +3-6 settimane (in base alle risorse esistenti). Totale: 4 settimane per un team piccolo, 8-10 settimane per uno medio, 12-16 settimane per una grande azienda. L'importante: si procede per fasi, senza fermare il business. I benefici arrivano appena termina la prima fase; ogni fase successiva aggiunge valore. Non aspettiamo un unico momento in cui «è tutto pronto».
Sì, e lo consideriamo parte del lavoro. Al termine della configurazione: (1) documentazione completa della pipeline in Markdown, (2) workshop pratico dal vivo di due giorni, (3) periodo di affiancamento di 30 giorni — noi osserviamo dietro le quinte, il team è in prima linea e noi rispondiamo alle domande. La vita quotidiana dello sviluppatore cambia molto poco: esegue git push e la pipeline parte. La complessità resta nascosta nell'infrastruttura. Per la parte operativa (gestione degli alert, runbook, rollback) organizziamo una rotazione di reperibilità. Dopo 3 mesi il suo team è abbastanza maturo da gestire la pipeline in autonomia.
Le voci sono due: (a) la nostra configurazione + 3 mesi di servizio di passaggio di consegne — il prezzo dipende dal progetto, nella fascia bassa delle quattro cifre per un progetto piccolo e nella fascia media delle cinque cifre per uno enterprise (in EUR/USD, prezzo fisso). (b) Costi continuativi dell'infrastruttura — li paga dal suo account cloud, noi non facciamo da intermediari. Valori tipici: SaaS piccolo 200-600 EUR al mese di cloud, medio 1.500-4.000 EUR, enterprise oltre 8.000. Nota importante: una progettazione corretta fa risparmiare il 30-50% dei costi cloud (rightsizing, spot instance, autoscaling). Di solito l'investimento in DevOps si ripaga in sei mesi.
Sì. AWS + GCP + Azure + Hetzner + DigitalOcean — abbiamo esperienza attiva in produzione su tutti. Terraform/Pulumi offrono un'astrazione indipendente dal fornitore; i manifest Kubernetes funzionano su qualsiasi cluster. Spesso il «multi-cloud» non è ciò che serve davvero (la complessità operativa aumenta di 2,5 volte) — di solito consigliamo un unico cloud primario + una regione diversa (multi-region) + un secondo provider per il disaster recovery. Se serve un vero multi-cloud (ad es. dati UE su AWS, dati USA su GCP), realizziamo anche quello. La scelta della regione per motivi di sovranità dei dati (GDPR/KVKK) è un tema che affrontiamo spesso.
Sì. Abbiamo realizzato pipeline conformi a ISO 27001, SOC2 Type II, PCI DSS, GDPR e KVKK (legge turca n. 6698 sulla protezione dei dati personali). Cosa mettiamo in atto: build immutabili (non modificabili a posteriori), separazione dei compiti (chi scrive il codice non può rilasciarlo), audit trail completo (chi ha approvato cosa e quando), secret cifrati (Vault/SOPS), cifratura a riposo e in transito, accesso alla produzione protetto da MFA, scansione delle vulnerabilità a ogni build. La documentazione per l'auditor è disponibile in template già pronti. Abbiamo oltre 6 casi in cui auditor indipendenti hanno approvato pipeline realizzate da noi — possiamo condividere le referenze.
Se dopo un rilascio si nota un problema, le strade sono due. (1) Kubernetes rollout undo: la revisione precedente è ancora nella cronologia del Deployment; con un comando o un pulsante nell'interfaccia di ArgoCD, la vecchia immagine torna attiva in pochi secondi, non in minuti. Tempo tipico: 12-25 secondi. (2) Se c'è una migrazione del database serve più attenzione: prima la migrazione inversa, poi il rollback del container. Per questo progettiamo sempre migrazioni retrocompatibili (pattern a due passaggi, come NULL allow → fill → NOT NULL). Regola di rollback automatico: una violazione dell'SLO o un picco del tasso di errore ferma in automatico il rollout progressivo di ArgoCD e, se necessario, lo annulla. L'intervento umano è facoltativo.
Smetta di temere i rilasci.
In un colloquio di 30 minuti valutiamo insieme la sua pipeline attuale. Dove si può guadagnare, quali passaggi sono critici — definiamo un piano concreto di 90 giorni.