Continuous Delivery (CD): cos'è, differenza da Continuous Deployment

Cos'è Continuous Delivery

Continuous Delivery (CD) è un'estensione di Continuous Integration che aggiunge automazione per tutte le fasi di preparazione del rilascio: compilazione del build di release, firma con certificati, offuscamento, verifica dei metadati dello store di app e deploy in staging. Il termine è stato introdotto da Jez Humble e David Farley nel libro “Continuous Delivery” (2010), dove hanno formalizzato la pratica che consente ai team di rendere i rilasci prevedibili e a basso rischio.

Evoluzione della consegna del software

Prima dell'adozione del CD, i rilasci erano un evento: il team si riuniva in una stanza, seguiva una checklist di 20 punti, eseguiva script manualmente e sperava che nulla si rompesse. Continuous Delivery trasforma un rilascio da evento a processo: una piccola modifica al codice può essere distribuita agli utenti in minuti, non settimane. Amazon, Netflix e Etsy sono state le prime ad adottare CD negli anni 2010 — oggi è lo standard per i team di prodotto.

Valore commerciale del CD

La consegna rapida delle funzionalità è un vantaggio competitivo. Se un concorrente rilascia nuove funzionalità in giorni mentre tu impieghi mesi, il mercato sceglie il concorrente. Le metriche DORA mostrano: i team elite (con CD) hanno un tempo di deploy inferiore a 1 ora, i team bassi (senza CD) — da 1 settimana a 1 mese. Il CD riduce anche radicalmente il rischio: le piccole modifiche sono più difficili da rompere rispetto a un grande rilascio trimestrale.

CD vs CI vs Continuous Deployment

I termini CI, CD e Continuous Deployment sono spesso confusi, ma esiste un confine chiaro tra di loro. Comprendere le differenze aiuta a progettare correttamente il pipeline e scegliere il livello di automazione che corrisponde alla maturità del team e ai requisiti aziendali.

Continuous Integration

CI è il fondamento su cui si basa CD. CI garantisce che ogni commit passi attraverso compilazione e test. Senza CI, CD è impossibile: se il codice non è verificato, non può essere rilasciato. CI verifica la correttezza, CD verifica la prontezza per l'uso commerciale.

Continuous Delivery

CD aggiunge a CI le fasi di compilazione del build di release, verifica dei metadati, firma e deploy in staging o nello store di app per test beta. La differenza chiave — la decisione di rilasciare in produzione è presa da una persona (manager, product owner). CD rende il rilascio “a un clic di distanza” — semplice e sicuro.

Continuous Deployment

Continuous Deployment è automazione completa: ogni modifica che supera tutte le fasi del pipeline CD viene inviata automaticamente in produzione senza approvazione manuale. Continuous Deployment è applicabile per prodotti SaaS e servizi web, ma è raramente utilizzato nello sviluppo mobile a causa delle politiche degli store di app (App Store Review, Google Play Review richiede invio manuale).

Continuous Delivery per applicazioni mobile

CD per applicazioni mobile ha caratteristiche che lo distinguono dai pipeline web e backend. I rilasci mobile passano attraverso gli store di app (App Store Review, Google Play Review), il che aggiunge una barriera di tempo e processo. CD automatizza tutto ciò che può essere automatizzato prima dell'invio per la revisione per massimizzare la probabilità di superare la verifica al primo tentativo.

Preparazione per la pubblicazione su Google Play

Il pipeline CD Android include: compilazione di AAB (Android App Bundle), firma con chiave di rilascio, offuscamento tramite R8/ProGuard, verifica della dimensione dell'APK e delle classi multidex, generazione delle note di rilascio. L'uso dei product flavors di Gradle (free/paid, dev/staging/prod) consente di gestire più configurazioni da un singolo pipeline.

Preparazione per la pubblicazione sull'App Store

Il CD iOS richiede firma con certificati tramite Fastlane match, verifica della conformità delle icone (requisito dell'App Store — 1024×1024 px), validazione dei metadati (nome, descrizione, parole chiave), verifica dell'assenza di API private. La validazione tecnica viene eseguita tramite altool --validate-app senza caricamento su App Store Connect, fornendo un feedback rapido.

# Fastfile — pipeline CD completa per iOS e Android
platform :ios do
  desc "CD iOS — preparazione del rilascio e upload su TestFlight"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "CD Android — compilazione AAB e upload su Google Play Console"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

Fastlane deliver_to_testflight raccoglie screenshot, ottiene certificati tramite match, compila IPA e carica su TestFlight. La lane deliver_to_internal per Android compila Release AAB tramite Gradle e lo carica sulla traccia interna di Google Play Console. Entrambi i pipeline vengono eseguiti da CI dopo il superamento dei test.

Componenti del pipeline CD

Un pipeline CD è costituito da fasi sequenziali, ognuna delle quali aggiunge fiducia che il rilascio sia pronto per gli utenti. Le fasi sono divise in tecniche (compilazione, firma) e di prodotto (metadati, screenshot, verifica delle descrizioni). Saltare qualsiasi fase aumenta il rischio che il rilascio venga rifiutato dallo store di app.

Gestione delle versioni

Un componente critico di CD è la gestione automatica delle versioni. L'incremento di versione (versionCode e versionName per Android, CFBundleVersion e CFBundleShortVersionString per iOS) viene eseguito in base ai tag Git o alla versione precedente nello store. Fastlane increment_version_number e i comandi Gradle (versionCode auto-increment) automatizzano questo passaggio.

Metadati dello store

Google Play Console e App Store Connect richiedono: descrizione dell'app, parole chiave, categoria, valutazione, link all'informativa sulla privacy. CD include la verifica della presenza e correttezza dei metadati. Fastlane deliver e supply automatizzano il caricamento di descrizioni, screenshot e icone insieme al build.

Verifiche di gate

Prima dell'invio per la revisione, il pipeline esegue verifiche di gate: verifica della dimensione del build (APK > 200 MB viene rifiutato da Google Play), presenza di tutte le localizzazioni, assenza di simboli di debug nel build di release, verifica del file di mapping ProGuard per decodificare i log di crash. Se una verifica fallisce — il pipeline blocca il rilascio.

Test automatizzati per CD

Il livello di fiducia nel CD è direttamente proporzionale alla qualità dei test automatizzati. Se i test non rilevano regressioni — il rilascio può rompere la produzione e il team perde fiducia nel CD. Il CD mobile richiede una piramide di test a tre livelli adattata alle specificità della piattaforma.

Test unitari

I test unitari verificano la logica di business in isolamento. La copertura del codice dovrebbe essere almeno del 70% per i moduli critici (autenticazione, pagamenti, rete). CI esegue test unitari a ogni push e, se falliscono — il pipeline CD viene bloccato fino alla correzione.

Test di integrazione

Verificano l'interazione dei componenti: layer di rete con API reale (o server mock), database, file system. I test Room DAO per Android, i test Core Data per iOS sono esempi di test di integrazione. Sono più lenti dei test unitari (1–5 minuti) e vengono eseguiti nella fase CD, non in CI a ogni commit.

Test UI e screenshot

Test screenshot (snapshot testing) confrontano le schermate dell'app con immagini di riferimento. Se una modifica al codice ha alterato l'interfaccia — il test fallisce e lo sviluppatore verifica se la modifica è prevista. Android supporta Roborazzi e Paparazzi, iOS — SnapshotTesting di Point-Free. I test screenshot vengono eseguiti prima del rilascio come parte del pipeline CD.

Migliori pratiche di Continuous Delivery

L'implementazione di Continuous Delivery richiede non solo strumenti ma anche un cambiamento nella cultura del team. Le pratiche seguenti si basano su anni di esperienza di team mobile di Google, Spotify e Uber e sono adattate per progetti di qualsiasi dimensione.

Feature Flags

Il codice di una nuova funzionalità viene distribuito in produzione ma nascosto dietro un flag. I Feature flags consentono di distribuire il codice prima che la funzionalità sia pronta per gli utenti e di disabilitarla istantaneamente in caso di problemi. Librerie: LaunchDarkly, Firebase Remote Config, Unleash. I Feature flags sono un requisito obbligatorio per CD nei progetti mobile.

Ambiente di staging

Prima della distribuzione in produzione, il build viene distribuito in staging — un ambiente identico alla produzione ma con dati di test. Gli ingegneri QA verificano la funzionalità su un build di staging installato tramite TestFlight o la traccia Internal Testing. Se lo staging supera — il build riceve l'approvazione per l'invio alla revisione dello store.

Note di rilascio e changelog

CD genera automaticamente le note di rilascio basate sui messaggi di commit. I Conventional Commits (feat:, fix:, chore:) e i tag Git in formato semantic versioning consentono di analizzare la cronologia delle modifiche. Fastlane changelog_from_git_commits raccoglie le modifiche tra gli ultimi due tag e le formatta per lo store di app.

Monitoraggio post-rilascio

CD non termina con la pubblicazione — dopo il rilascio, inizia il monitoraggio: tasso di crash, tasso ANR per Android, tempo di avvio, tasso di fallimento dei pagamenti. Se le metriche superano i limiti normali — il pipeline CD deve automaticamente annullare il rilascio o notificare il team. Strumenti: Firebase Crashlytics, Sentry, New Relic.

// Esempio di Feature Flag con Firebase Remote Config per CD
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// Utilizzo nel codice
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}