CI/CD Pipeline — cos'è, fasi di automazione e strumenti

Cos'è CI/CD Pipeline

CI/CD Pipeline è un insieme formalizzato e automatizzato di processi che il codice attraversa dal momento del commit delle modifiche nel repository fino al deployment in produzione. Il termine unisce due pratiche: Continuous Integration (integrazione continua) e Continuous Delivery (consegna continua), che insieme formano una pipeline di distribuzione del software.

Storia del CI/CD

Il concetto di Continuous Integration è stato descritto da Grady Booch nel 1991 e reso popolare da Martin Fowler negli anni 2000. Continuous Delivery come termine si è affermato dopo il libro “Continuous Delivery” di Jez Humble e David Farley (2010). Il moderno CI/CD Pipeline è diventato lo standard de facto nello sviluppo mobile dopo il 2015 — con l'emergere di server CI cloud e l'automazione degli store di applicazioni.

Perché il CI/CD Pipeline è necessario nello sviluppo mobile

Le applicazioni mobili hanno requisiti specifici di build e pubblicazione: firma di certificati, configurazioni multiple (debug, release, staging), offuscamento ProGuard/R8, tipi di build multipli (APK, AAB, IPA) e integrazione con gli store di applicazioni. L'esecuzione manuale di questi passaggi richiede ore ed è soggetta a errori — il CI/CD Pipeline automatizza la routine.

Fasi del CI/CD Pipeline per app mobili

Un CI/CD Pipeline standard per applicazioni Android o iOS consiste in sette fasi chiave. Alcune fasi vengono eseguite in parallelo, altre sequenzialmente. L'insieme esatto delle fasi dipende dallo stack tecnologico e dalla maturità del team, ma il nucleo rimane invariato.

1. Checkout e installazione delle dipendenze

La pipeline inizia con la clonazione del repository e l'installazione delle dipendenze: Gradle/Maven per Android, CocoaPods o SPM per iOS. La memorizzazione nella cache delle dipendenze tra le esecuzioni riduce il tempo di installazione da 3–5 minuti a pochi secondi — tutti i servizi CI moderni supportano questa ottimizzazione.

2. Analisi statica e linting

Prima della build, il codice viene verificato da linter (ktlint, detekt per Android, SwiftLint per iOS) e analizzatori statici (Android Lint, SonarQube). Il linting rileva potenziali bug, violazioni dello stile del codice e API deprecate prima dell'esecuzione dei test — il principio fail-fast fa risparmiare tempo al team.

3. Build del progetto

Nella fase di build, l'intero progetto viene compilato e vengono generati artefatti: APK e AAB per Android, IPA per iOS. Per Android vengono utilizzati task Gradle (assembleDebug, bundleRelease), per iOS — xcodebuild o xcrun. La build viene eseguita in un ambiente isolato del server CI, garantendo la riproducibilità.

# Esempio di Pipeline CI/CD per Android su GitHub Actions
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. Test automatizzati

Dopo la build, vengono eseguiti test unitari, test di integrazione e test dell'interfaccia utente. JUnit e MockK per i test unitari, Espresso e Compose Test per l'interfaccia Android, XCTest e XCUITest per iOS. I risultati vengono pubblicati in un report e bloccano la pipeline in caso di fallimento dei test critici.

5. Firma e offuscamento

Per le build di rilascio, vengono effettuati la firma con certificato digitale (APK Signer per Android, codesign per iOS) e l'offuscamento del codice. ProGuard o R8 per Android riduce la dimensione dell'APK del 15–30%. Le chiavi di firma sono conservate nei segreti del server CI — mai commitate nel repository.

6. Consegna e deployment

La fase finale della pipeline è la pubblicazione degli artefatti: caricamento dell'APK nei test interni di Google Play Console, invio dell'IPA a TestFlight o pubblicazione in Firebase Distribution. Continuous Delivery significa che questo passaggio richiede un'approvazione manuale, mentre Continuous Deployment viene eseguito automaticamente.

7. Notifiche e report

Al completamento della pipeline, il team riceve una notifica con i risultati: successo/fallimento, tempo di esecuzione, link agli artefatti. Slack, Telegram o email — i canali di notifica vengono scelti in base alle esigenze del team. Quando una fase fallisce, la notifica include un link al log di errore specifico.

Differenza tra CI e CD

I termini CI e CD sono spesso usati come unico concetto CI/CD, ma esiste una differenza fondamentale tra loro. CI (Continuous Integration) è responsabile della verifica della qualità a ogni integrazione del codice, mentre CD (Continuous Delivery) garantisce che il codice sia pronto per il rilascio. Comprendere la differenza è fondamentale quando si progetta una pipeline.

Continuous Integration — controllo qualità

CI viene eseguito a ogni push o pull request e include build, analisi statica e test. L'obiettivo di CI è rilevare i problemi il prima possibile, quando il costo per risolverli è minimo. Se CI fallisce — il codice non entra nel ramo principale. Il tempo medio di esecuzione di CI per un progetto mobile è di 5–15 minuti.

Continuous Delivery — preparazione al rilascio

CD aggiunge a CI le fasi di preparazione al rilascio: firma, offuscamento, creazione di note di rilascio, verifica delle licenze, pubblicazione nell'archivio per i tester. CD garantisce che qualsiasi commit nel ramo principale possa essere distribuito in produzione con un clic, ma il rilascio stesso richiede approvazione manuale.

Strumenti per costruire CI/CD Pipeline

L'ecosistema degli strumenti CI/CD per lo sviluppo mobile include servizi cloud, soluzioni self-hosted e piattaforme specializzate. La scelta dello strumento dipende dalle dimensioni del team, dal budget e dai requisiti di sicurezza. Di seguito sono riportate le opzioni più popolari.

GitHub Actions

CI/CD integrato in GitHub con un limite gratuito di 2000 minuti al mese per repository pubblici. GitHub Actions è popolare grazie al vasto ecosistema di azioni pronte (marketplace), alla facile configurazione tramite YAML e all'integrazione perfetta con i repository GitHub. Limitazione — nessun supporto per runner Windows per build iOS nel piano gratuito.

GitLab CI/CD

Soluzione self-hosted e cloud con un potente configuratore YAML. GitLab CI supporta job paralleli, caching, artefatti e ambienti. Popolare nel segmento enterprise grazie alla possibilità di distribuire sulla propria infrastruttura e al controllo completo dei dati.

Jenkins

Server CI open source classico. Jenkins viene configurato tramite plugin (oltre 1800), supporta Declarative Pipeline in formato Groovy e funziona in qualsiasi ambiente: Windows, macOS, Linux. Richiede amministrazione dedicata ma offre la massima flessibilità di configurazione.

CircleCI

Servizio CI cloud focalizzato su velocità e semplicità. CircleCI memorizza automaticamente nella cache le dipendenze, supporta immagini Docker per build isolate e si integra con macOS per build iOS. Il prezzo è basato su crediti — adatto a team che apprezzano le prestazioni.

Esempio di configurazione CI/CD Pipeline

Vediamo una CI/CD Pipeline completa per un'app iOS utilizzando GitHub Actions e Fastlane. Fastlane è uno strumento di automazione per progetti mobili che astrae operazioni complesse di build, firma e pubblicazione in comandi semplici.

# Fastfile — configurazione di Fastlane per iOS CI/CD
default_platform(:ios)

platform :ios do
  desc "Esecuzione dei test e linting"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "Build della release e caricamento su TestFlight"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match gestisce certificati e profili di provisioning, build_app compila IPA, pilot carica la build su TestFlight. Il comando fastlane release esegue tutte le fasi sequenzialmente: recupera i certificati, compila, firma, carica su App Store Connect per i tester beta.

CI/CD Pipeline per iOS con GitHub Actions

L'integrazione di Fastlane con GitHub Actions consente di eseguire l'intera pipeline automaticamente al pull request nel ramo principale. È necessario un runner self-hosted su macOS per la compilazione del codice iOS — GitHub non fornisce runner macOS nel piano gratuito.

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

Best practice CI/CD Pipeline

Costruire un CI/CD Pipeline efficace richiede non solo la scelta degli strumenti ma anche il seguire pratiche comprovate. Senza una corretta organizzazione, la pipeline può diventare un collo di bottiglia, rallentando lo sviluppo invece di accelerarlo. Di seguito le principali raccomandazioni basate sull'esperienza di team mobile maturi.

Fail fast

I controlli più veloci (linting, test unitari) vengono eseguiti per primi. Se falliscono — la pipeline termina senza eseguire lunghi test UI o build di rilascio. Fail fast risparmia minuti di tempo CI e accelera il feedback allo sviluppatore. Il tempo medio fino al primo fallimento non dovrebbe superare i 2–3 minuti.

Caching delle dipendenze

La cache di Gradle, CocoaPods e SPM dovrebbe essere ripristinata tra le esecuzioni. GitHub Actions supporta il caching tramite actions/cache, GitLab CI tramite la parola chiave cache. Senza caching, ogni build scarica tutte le dipendenze da zero — aggiungendo 3–10 minuti al tempo della pipeline.

Esecuzione parallela

Le fasi indipendenti (linter per Android e iOS, test unitari di moduli diversi) vengono eseguite come job paralleli. La parallelizzazione riduce il tempo totale della pipeline da 20–30 minuti a 5–10 minuti. La maggior parte dei servizi CI addebita i job paralleli separatamente — tienilo presente quando scegli un piano.

Isolamento dell'ambiente

Ogni esecuzione della pipeline viene effettuata in un ambiente pulito: container Docker, macchina virtuale o runner effimero. L'isolamento impedisce che le build precedenti influenzino quella corrente. Evita di utilizzare runner condivisi tra progetti — l'inquinamento incrociato dell'ambiente porta a fallimenti non deterministici.

Sicurezza dei segreti

Le chiavi API, i certificati di firma e i token di accesso agli store di applicazioni sono conservati nel vault crittografato del server CI. Non includere mai segreti in log, artefatti o variabili d'ambiente senza il prefisso SECRET_. Utilizza strumenti come Fastlane match per la gestione dei certificati iOS.