---
term: 'CI/CD (continuous integration e delivery)'
seoTitle: 'CI/CD: che cos''è, pipeline e metriche DORA'
headline: 'Che cos''è il CI/CD (continuous integration e delivery)?'
slug: ci-cd
category: cloud-architecture
shortDefinition: 'Il CI/CD è una pratica che automatizza build, test e rilascio del codice, così ogni modifica passa dal commit alla produzione a piccoli passi.'
relatedTerms:
  - no-ops-development
  - containerization
  - kubernetes
  - backend-boilerplate-code
  - cloud-code-serverless-functions
contrastsWith:
  - no-ops-development
faq:
  - question: 'Che cosa significa CI/CD?'
    answer: 'Continuous Integration e Continuous Delivery – con un''ambiguità incorporata che conviene conoscere: la "CD" può indicare anche il continuous deployment. La delivery mantiene un''approvazione umana prima della produzione; il deployment la elimina. Quando qualcuno dice "facciamo CI/CD", la domanda utile è sempre quale CD intenda.'
  - question: 'Che cos''è la continuous integration?'
    answer: 'La pratica di unire piccole modifiche in un mainline condiviso con frequenza – almeno una volta al giorno, nella definizione canonica – con ogni merge che innesca una build e un''esecuzione automatica dei test. Il punto è il feedback rapido: i problemi di integrazione emergono pochi minuti dopo essere stati creati, invece di settimane più tardi nella corsa a un rilascio.'
  - question: 'Qual è la differenza tra continuous delivery e continuous deployment?'
    answer: 'Un solo passaggio di approvazione manuale. Con la continuous delivery ogni modifica viene costruita, testata e tenuta rilasciabile in automatico, ma è una persona a decidere quando la produzione si aggiorna davvero. Con il continuous deployment non c''è barriera: ogni modifica che supera la pipeline va in linea automaticamente, e solo un test fallito la ferma.'
  - question: 'Che cos''è una pipeline CI/CD?'
    answer: 'Il flusso automatizzato che una modifica percorre dal commit alla produzione: innesco sul sorgente, build, test automatici, consegna in un ambiente di staging e deployment. Ogni fase deve passare prima che parta la successiva, così la pipeline fa da barriera di qualità che ogni modifica supera allo stesso modo – nessun caso speciale, nessun eroismo al momento del deployment.'
  - question: 'Che cosa sono le metriche DORA?'
    answer: 'Il modo standard del settore per misurare le prestazioni di rilascio, nato dal programma di ricerca DORA: frequenza di deployment, lead time delle modifiche, tasso di fallimento delle modifiche, tempo di ripristino dopo un deployment fallito e – aggiunto più di recente – tasso di rilavorazione dei deployment. Il risultato di punta della ricerca è che velocità e stabilità non sono un trade-off: chi va meglio ottiene punteggi alti su entrambe.'
  - question: 'Il CI/CD è la stessa cosa del DevOps?'
    answer: 'No – il DevOps è la cultura più ampia che unisce sviluppo e operations; il CI/CD ne è la spina dorsale di automazione. Si possono adottare gli strumenti di CI/CD senza la cultura (aiuta meno del previsto) e predicare la cultura senza l''automazione (cambia meno di quanto promesso). Le due pratiche si rinforzano a vicenda, ma indicano cose diverse.'
  - question: 'Quali test girano in una pipeline CI/CD?'
    answer: 'Stratificati per velocità: unit test e analisi statica a ogni commit, perché sono rapidi; i test di integrazione verificano i componenti su dipendenze reali; end-to-end, performance e scansioni di sicurezza girano nelle fasi successive o secondo una pianificazione, perché sono lenti. La regola di progetto: più rapido è il feedback, più presto arriva la fase.'
  - question: 'Alle squadre piccole serve il CI/CD?'
    answer: 'Serve la pratica, più dell''impianto. Anche una squadra di due persone trae vantaggio da test automatici su ogni modifica e da deployment con un solo comando – è CI/CD nella sostanza. Quello che le squadre piccole fanno bene a evitare è gestire un''infrastruttura di pipeline pesante; runner gestiti o piattaforme con il deployment incorporato riducono la pratica a configurazione.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Continuous Integration — Martin Fowler (updated 2024)'
    url: 'https://martinfowler.com/articles/continuousIntegration.html'
  - name: 'Continuous Delivery — Martin Fowler'
    url: 'https://martinfowler.com/bliki/ContinuousDelivery.html'
  - name: 'DORA metrics guide (dora.dev)'
    url: 'https://dora.dev/guides/dora-metrics-four-keys/'
  - name: 'CI/CD (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/CI/CD'
cta:
  title: 'Deployment senza impiantistica di pipeline'
  text: 'Back4app comprime la metà delivery del CI/CD: le funzioni Cloud Code si distribuiscono con un comando da CLI o direttamente da un repository Git, con database, autenticazione e API già attivi. Tieni i tuoi test; lascia perdere il parco di runner.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-19'
translationKey: ci-cd
---

**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

| Domanda | Risposta |
| --- | --- |
| Che cos'è | Automazione che trasforma il "giorno del rilascio" in un non evento continuo |
| CI | Unire piccole modifiche ogni giorno; ogni merge lancia build e test automatici |
| Le due CD | La delivery mantiene un'approvazione umana prima della produzione; il deployment la elimina |
| Perché funziona | Le modifiche piccole falliscono in piccolo; il feedback rapido intercetta i bug pochi minuti dopo |
| Come si misura | Le cinque metriche DORA – velocità e stabilità salgono insieme |

## 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:

```yaml
# 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:**

```javascript
// 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
// 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
}
```

**Swift:**

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

**Kotlin:**

```kotlin
// 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

| Dimensione | Continuous integration | Continuous delivery | Continuous deployment |
| --- | --- | --- | --- |
| Ambito | Merge + build + test | …più artefatti sempre rilasciabili | …più il rilascio automatico |
| Innesco | Ogni commit sul mainline | Ogni build riuscita | Ogni build riuscita |
| Barriera umana | Nessuna (i test sono la barriera) | **Sì – un'approvazione di rilascio** | **Nessuna** |
| Aggiornamento della produzione | Quando qualcuno rilascia | Quando qualcuno clicca | In continuazione |
| Adatto a | Tutti | Rilasci regolamentati, lanci scanditi dal marketing | Backend web, SaaS, suite di test affidabili |

```mermaid
flowchart LR
  accTitle: Una pipeline CI/CD
  accDescr: I commit innescano fasi automatiche di build e test; le modifiche che passano arrivano in staging, poi attraversano una barriera di approvazione manuale con la continuous delivery, oppure nessuna barriera con il continuous deployment, fino alla produzione.
  A[Commit] --> B[Build] --> C[Test automatici] --> D[Staging]
  D --> E{Approvazione manuale?}
  E -- "sì – continuous delivery" --> F[Produzione]
  E -- "nessuna barriera – continuous deployment" --> F
```

La genealogia merita una frase: [l'articolo di riferimento di Martin Fowler](https://martinfowler.com/articles/continuousIntegration.html) 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](https://dora.dev/guides/dora-metrics-four-keys/) – 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

| Scegliere il continuous deployment quando… | Tenere la barriera della delivery quando… |
| --- | --- |
| La suite di test è affidabile per la produzione | La copertura dei test sta ancora crescendo verso quella fiducia |
| Il rollback è un comando solo | Il rollback è un progetto |
| Gli utenti si aspettano aggiornamenti invisibili e costanti | I rilasci si allineano a date di marketing o di contratto |
| Il prodotto è un backend web o un SaaS | Il prodotto passa dalla revisione di uno store |
| I guasti degradano con grazia dietro i feature flag | Un rilascio sbagliato ha conseguenze normative |

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.