Che cos'è il CI/CD (continuous integration e delivery)?

Il CI/CD è una pratica che automatizza build, test e rilascio del codice, così ogni modifica passa dal commit alla produzione a piccoli passi. La sigla comprime due idee – continuous integration (unire e verificare in continuazione) e continuous delivery (tenere ogni modifica pronta al rilascio) – più una famosa ambiguità: la seconda “D” può indicare anche il continuous deployment, dove tra un commit e la produzione non c’è altro che un test fallito.

Punti chiave

Che aspetto ha davvero una pipeline

Tutta la pratica sta in un unico file di configurazione – è l’artefatto che ogni pagina “CI/CD spiegato” descrive e che quasi nessuna mostra:

# pipeline.yml – l'automazione che sostituisce il "giorno del deploy"
on: push to main

jobs:
  build:
    steps:
      - checkout
      - run: npm ci && npm run build
  test:
    needs: build
    steps:
      - run: npm test            # unit + integrazione, a ogni commit
      - run: npm run lint        # analisi statica
  deploy:
    needs: test
    approval: manual             # eliminare questa riga → continuous deployment
    steps:
      - run: npm run deploy

Pochi minuti dopo l’esecuzione di quell’ultimo passaggio, ogni client chiama già la nuova versione del backend – ed è esattamente questo il punto:

// JavaScript / Node.js — Back4app JS SDK
// Seconds after `b4a deploy`, every client is calling the new version
const version = await Parse.Cloud.run('version');
console.log(`API version: ${version}`); // no pipeline YAML, no runners

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('version');
final response = await function.execute();
if (response.success) {
  print('API version: ${response.result}'); // fresh from the deploy
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("version") { result in
  if case .success(let version) = result {
    print("API version: \(version)") // fresh from the deploy
  }
}

// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("version", hashMapOf()) { version, e ->
  if (e == null) Log.d("API", "version: $version") // fresh from the deploy
}

CI vs. continuous delivery vs. continuous deployment

La genealogia merita una frase: l’articolo di riferimento di Martin Fowler ha definito la continuous integration nel 2000, il libro Continuous Delivery del 2010 l’ha estesa al processo di rilascio e il DevOps ne ha fatto la propria colonna portante di automazione. Un’osservazione tagliente di Fowler continua a valere: far girare un server di build su feature branch di lunga durata è “semi-integrazione” – fare continuous integration per davvero significa che il mainline integra il lavoro di tutti almeno una volta al giorno.

La pipeline, fase per fase

• Sorgente. Un commit o un merge innesca tutto. Nessuna build manuale, mai – se non viene innescata, non è continuous integration.
• Build. Compilare, risolvere le dipendenze, produrre l’artefatto (bundle, immagine del container) che ogni fase successiva riusa – costruire una volta, promuovere ovunque.
• Test. Prima i controlli rapidi: unit test e lint a ogni commit; poi i test di integrazione su dipendenze reali; end-to-end, performance e scansioni di sicurezza nelle fasi successive o in esecuzioni pianificate. L’ordine delle fasi lo decide la velocità del feedback.
• Delivery. L’artefatto arriva in un ambiente di staging simile alla produzione. Con la continuous delivery aspetta qui – rilasciabile – un sì umano.
• Deployment. La produzione. Le pipeline mature rilasciano in modo graduale – una fetta canary o un ambiente blue-green parallelo – così una modifica difettosa è un rollback circoscritto, non un disservizio.

Come si misura: le metriche DORA

“Siamo bravi a rilasciare?” ha una risposta standard: le cinque metriche del programma di ricerca DORA – frequenza di deployment, lead time delle modifiche, tasso di fallimento delle modifiche, tempo di ripristino dopo un deployment fallito e tasso di rilavorazione dei deployment. Il risultato più citato della ricerca è che il classico compromesso tra velocità e stabilità è falso: le squadre che rilasciano più spesso sono anche quelle che rompono meno, perché modifiche piccole e frequenti sono singolarmente a basso rischio e rapide da diagnosticare. Se il lavoro sulla pipeline non muove una delle cinque, è manutenzione dell’impianto, non progresso.

Casi d’uso comuni

• Backend web e API – la casa naturale del continuous deployment completo: alto volume di modifiche, rollback istantaneo, nessun passaggio di installazione.
• App mobile – continuous integration più delivery: le pipeline costruiscono, testano e preparano ogni modifica, mentre la revisione dello store rende l’ultimo passaggio per forza di cose soggetto a barriera.
• Squadre che crescono oltre un solo addetto al rilascio – la pipeline sostituisce l’unica persona che “sa come si rilascia” con un processo che chiunque può eseguire.
• Ambienti regolamentati – la barriera di approvazione diventa una feature: automazione completa fino alla linea, una decisione umana verificabile sulla linea.
• Progetti open source – ogni pull request costruita e testata in automatico è la continuous integration che fa da porta d’ingresso al progetto.

Conviene mettere una barriera davanti alla produzione? Matrice decisionale

La sequenza onesta: il deployment si guadagna praticando la delivery – automatizzare tutto fino alla barriera, tenere d’occhio il tasso di fallimento e togliere la barriera quando non sta più facendo nulla.

Limiti e trade-off

• La pipeline è codice di cui si risponde. Runner, YAML, cache, segreti – tutto va mantenuto e, a certe dimensioni di squadra, la pipeline diventa un prodotto a sé con la propria reperibilità.
• I test instabili avvelenano tutto. Una suite che fallisce a caso abitua le persone a cliccare “riprova”, il che riconverte in silenzio il continuous deployment in deployment manuale con qualche passaggio in più.
• La cultura è un prerequisito, non un sottoprodotto. Merge piccoli, sviluppo sul mainline e riparare subito le build rosse sono abitudini; comprare una pipeline non le installa.
• Velocità senza osservabilità è azzardo. Rilasciare in continuazione è sicuro solo se i guasti si vedono in fretta – monitoring e alerting fanno parte della pratica, non sono un’aggiunta.
• L’ultimo miglio varia. Database, migrazioni e servizi con stato resistono al “basta ridistribuire”; la pipeline ha bisogno di strategie (migrazioni expand-contract, feature flag) che nessun YAML scrive al posto di chi sviluppa.

Il CI/CD su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. L’effetto sul CI/CD è una sottrazione sul versante della delivery: Cloud Code si distribuisce con un solo comando da CLI oppure direttamente da un repository Git, e il backend standard – database, autenticazione, API – non compare affatto nella pipeline, perché non c’è nulla da costruire né da rilasciare. Resta la metà che vale la pena tenere: i propri test, in esecuzione a ogni commit, davanti a un passaggio di deployment ora lungo una riga.