import pandas as pd

CI/CD per pipeline dati

Una modifica a un modello dbt sembra innocua finché non rompe la dashboard del board un lunedì mattina. Il CI/CD per i dati nasce per evitare scene del genere: intercetta errori di schema, test falliti, dipendenze non dichiarate e deploy non riproducibili prima che arrivino in produzione. In questa lezione lo trattiamo come una scelta operativa, non come una definizione da imparare a memoria. La domanda che conta è quale rischio riduci quando il rilascio di una modifica ai dati diventa sicuro.

Il problema da risolvere

Conoscere il CI/CD in astratto non serve. Serve sapere cosa fare quando il team rilascia modelli con dati incompleti, dipendenze opache o ambienti che divergono da quelli di produzione. Una lezione utile separa il segnale dal rumore: dice quale baseline usare, quale controllo eseguire e quale azione diventa difendibile dopo che la pipeline ha girato.

Il punto di partenza è il ciclo di vita di un cambiamento. Il CI/CD porta nel lavoro analitico la stessa disciplina che il software ha imparato da tempo: ogni modifica passa per un branch, un ambiente isolato, una build, dei test e una review prima di toccare la produzione. Il valore non è automatizzare tutto, ma rendere sicuro cambiare i dati senza affidarsi agli utenti perché scoprano gli errori al posto tuo.

Come ragionare sulla decisione

Conviene leggere ogni intervento come una sequenza che collega scelta, evidenza e rischio. La tabella sotto funziona da mappa di lavoro e impedisce che il CI/CD diventi un rituale vuoto.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se rendiamo sicuro il rilascio?	Scelta esplicita
Segnale	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Confronto credibile
Vincolo	Che cosa puo falsare la lettura?	Assunzione da dichiarare
Azione	Quale passo operativo segue?	Raccomandazione controllabile

Ogni riga deve rendere piu chiaro il costo di una decisione sbagliata. Se un passaggio non incide su una scelta concreta, diventa documentazione o teatro analitico.

Formalizzare unita, segnale e decisione

Per analizzare il CI/CD conviene fissare prima l’unita di lavoro, poi il segnale, poi la decisione attesa. L’unita di analisi qui è il job, la pipeline, il servizio, l’alert, il deploy o la risorsa cloud. Il segnale principale è SLA, MTTR, costo, failure rate, freshness o qualità dei dati. La decisione attesa è un runbook, un alert, una policy di costo, una configurazione CI/CD o un piano di recovery.

Elemento	Definizione operativa	Controllo minimo
Unita di analisi	Oggetto su cui misuri il fenomeno	job, pipeline, servizio, alert, deploy o risorsa cloud
Variabile osservata	Segnale che rappresenta il comportamento	SLA, MTTR, costo, failure rate, freshness, qualità dati
Baseline	Stato contro cui confronti il segnale	Periodo, segmento, controllo o benchmark
Soglia decisionale	Punto in cui cambia l’azione	Criterio scritto prima della lettura
Rischio residuo	Errore che puo restare anche dopo l’analisi	Scambiare un numero disponibile per una prova sufficiente

La formalizzazione non complica la lezione. Rende visibili le assunzioni, così un altro analista può riprodurre la logica, criticare le ipotesi e arrivare alla stessa decisione partendo dagli stessi dati.

I principi del CI/CD per dati

Cinque principi reggono l’intera pratica. Ogni analista o sviluppatore lavora sul proprio schema di sviluppo, mai direttamente su produzione. A ogni pull request scatta una build automatica con dbt build --select state:modified+ su uno schema CI dedicato, e se la build fallisce la PR non si merge. Il deploy è progressivo: il merge su main costruisce su staging, segue una validazione di 24 ore e solo dopo si arriva in produzione, perché lo staging è obbligatorio. Quando un deploy in produzione causa errori, il rollback è atomico tramite revert Git e rebuild, oppure con un blue/green deployment a switch immediato. Infine la data quality vive dentro la CI: ogni modello ha test not_null, unique e accepted_values che girano a ogni PR e la bloccano se falliscono.

Configurazione GitHub Actions per dbt

name: dbt CI
on:
  pull_request:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    environment: ci
    steps:
      - uses: actions/checkout@v3
      - name: Install dbt
        run: pip install dbt-snowflake
      - name: Build modified models
        env:
          SNOWFLAKE_USER: ${{ secrets.SNOWFLAKE_USER }}
          SNOWFLAKE_PASSWORD: ${{ secrets.SNOWFLAKE_PASSWORD }}
        run: |
          dbt deps
          dbt build --select state:modified+ --target ci \
            --defer --state ./target/

Il flag --defer --state fa la differenza: esegui solo i modelli modificati e gli altri li prendi in prestito dalla produzione. La CI passa così da ore a minuti.

Orchestration CI/CD per Airflow e Dagster

Per le pipeline di orchestrazione il pattern cambia. I DAG sono codice: file Python versionati, dove cambiare la pipeline significa cambiare codice. Gli ambienti restano separati tra dev, staging e prod, ciascuno con il proprio scheduler e database di metadati. Prima di rilasciare conviene eseguire i DAG in modalità test con dati sintetici, così l’integrazione viene verificata a vuoto. E per le modifiche più delicate il canary deployment attiva il nuovo DAG su una frazione dei dati, ne verifica l’output e poi scala al cento per cento.

Esempio: accelerare i rilasci senza più incidenti

Un team vuole permettere agli analisti di rilasciare modelli più spesso. Prima di accelerare introduce ambienti di sviluppo isolati, test su chiavi e valori null, controllo del lineage e build automatica sulle modifiche. Così la velocità aumenta senza moltiplicare gli incidenti. La tabella sotto mostra come leggere alcune evidenze tipiche.

Evidenza osservata	Lettura prudente	Azione consigliata
Il numero migliora	Potrebbe essere effetto reale o variazione normale	Cercare confronto e segmento
Un segmento cambia più degli altri	La media aggregata nasconde una differenza	Separare coorti o casi d’uso
Il costo cresce insieme al risultato	L’impatto va letto sul margine	Stimare trade-off e sostenibilità
Il sistema produce numeri incoerenti	La fiducia nel dato è parte della decisione	Correggere ownership e controlli

La domanda non è “qual è la definizione corretta di CI/CD?” ma “quale scelta diventa meno rischiosa se la pipeline è fatta bene?”.

Esempio SQL: costruire una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. Crea una base analitica con metrica, segmento e finestra temporale, così da confrontare periodi e gruppi senza riscrivere la logica ogni volta.

WITH base_events AS (
  SELECT
    user_id,
    account_id,
    event_type,
    event_time,
    DATE_TRUNC('week', event_time) AS week,
    source,
    device_type
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '180 days'
    AND user_id IS NOT NULL
),
weekly_user_metrics AS (
  SELECT
    week,
    user_id,
    COALESCE(source, 'unknown') AS source,
    COALESCE(device_type, 'unknown') AS device_type,
    COUNT(*) AS total_events,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(DISTINCT event_type) AS event_diversity,
    MAX(CASE WHEN event_type IN ('purchase', 'subscribe', 'activation') THEN 1 ELSE 0 END) AS reached_key_outcome
  FROM base_events
  GROUP BY week, user_id, source, device_type
)
SELECT
  week,
  source,
  device_type,
  COUNT(DISTINCT user_id) AS users,
  ROUND(AVG(active_days), 2) AS avg_active_days,
  ROUND(AVG(event_diversity), 2) AS avg_event_diversity,
  ROUND(AVG(reached_key_outcome) * 100, 2) AS key_outcome_rate
FROM weekly_user_metrics
GROUP BY week, source, device_type
ORDER BY week, source, device_type;

La query non pretende di dare la risposta finale. Serve a creare una superficie di osservazione: trend, segmenti, differenze tra canali, variazioni nel tempo. Da qui l’analista formula ipotesi più precise.

Esempio Python: controllare stabilità e anomalie

Una metrica utile deve essere abbastanza stabile da orientare decisioni e abbastanza sensibile da segnalare cambiamenti reali. In Python possiamo controllare le variazioni anomale settimana su settimana.

# df contiene: week, segment, users, key_outcome_rate
# key_outcome_rate espresso in percentuale, es. 12.4

df = df.sort_values(['segment', 'week']).copy()
df['previous_rate'] = df.groupby('segment')['key_outcome_rate'].shift(1)
df['wow_change_pp'] = df['key_outcome_rate'] - df['previous_rate']
df['rolling_mean'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).mean()
)
df['rolling_std'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).std()
)
df['z_score'] = (df['key_outcome_rate'] - df['rolling_mean']) / df['rolling_std']

anomalies = df[df['z_score'].abs() >= 2].sort_values('z_score')
print(anomalies[['week', 'segment', 'key_outcome_rate', 'wow_change_pp', 'z_score']])

Il controllo evita di reagire a ogni oscillazione casuale ma segnala quando una variazione merita un’indagine. In azienda alimenta alert, review settimanali e retrospettive di prodotto.

Caso reale: Netflix e la disciplina delle metriche

Netflix è un esempio utile perché ha costruito molte decisioni di prodotto intorno a segnali comportamentali osservabili: completamento degli episodi, tempo di ricerca prima della riproduzione, abbandono dopo pochi minuti, ritorno nella settimana successiva, efficacia delle raccomandazioni. Il punto non è copiare Netflix, ma il metodo: il dato non è un ornamento, è infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, per esempio una nuova riga di raccomandazioni, una diversa immagine di copertina o un nuovo algoritmo di ranking, non misura solo il click immediato. Guarda anche i segnali di qualità: l’utente guarda davvero il contenuto? torna nei giorni successivi? riduce il tempo speso a cercare? Questa disciplina evita di ottimizzare vanity metric che sembrano positive nel breve periodo ma erodono valore nel lungo. Lo stesso vale per il CI/CD: se non è collegato a un outcome, l’analisi resta incompleta.

Esercizio

Al livello base, scrivi in cinque righe quale decisione concreta dovrebbe migliorare il CI/CD per i tuoi dati, indicando metrica, unita di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, il tema è ancora troppo astratto.

Al livello intermedio, costruisci una tabella con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario, azione consigliata. Includi almeno un caso in cui il segnale non basta per decidere.

Al livello research-grade, trasforma l’esercizio in un decision memo con assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Come materiale usa log pipeline, metriche dell’orchestratore, cost explorer, incident report e dashboard ops; se non hai dati reali, genera un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Errori comuni da evitare

L’errore più frequente è usare il CI/CD come etichetta tecnica invece che come criterio di scelta: il team mostra un grafico senza decisione, una metrica senza baseline, una conclusione senza dire quale assunzione potrebbe invalidarla. La domanda di controllo è semplice: se questo risultato fosse instabile, quale scelta sbaglierei?

Tre errori ricorrenti restano in agguato. Il primo è lavorare su dati aggregati troppo presto, perché una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Il terzo è confondere correlazione e causalità, perché gli utenti che usano una feature potrebbero convertire di più solo perché erano già più motivati. Per ridurre questi rischi, ogni analisi dovrebbe includere definizione esplicita della metrica, confronto per segmento e verifica contro un periodo precedente o un gruppo di controllo.

Checkpoint

Prima di chiudere, prova a rispondere. Quale decisione concreta dovrebbe migliorare questa lezione? Quale unita di analisi rende il problema misurabile? Quale baseline useresti per evitare una lettura isolata? Quale assunzione, se falsa, cambierebbe la conclusione? Quale controllo presenteresti a uno stakeholder prima di raccomandare un’azione?

Riepilogo

Il CI/CD per pipeline dati è uno strumento decisionale, non un argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione. Una buona analisi non finisce con “il numero è salito” o “il numero è sceso”, ma con una frase operativa: quale decisione prendiamo, con quale confidenza, e quale metrica useremo per sapere se avevamo ragione. La forma utile resta sempre la stessa: decisione, segnale, baseline, rischio e azione. Tutto il resto serve solo se rende più affidabile uno di questi passaggi.