Git workflow, code review e collaborazione tecnica

Quando più persone lavorano sugli stessi modelli che alimentano dashboard critici, il workflow Git smette di essere un dettaglio e diventa parte della qualità del dato. Pull request, revisioni, naming e ownership entrano nel lavoro quotidiano dell’analytics engineer, perché ogni modifica può cambiare un numero che qualcun altro userà per decidere.

Il problema da risolvere

In analytics engineering il compito è trasformare dati grezzi in modelli testati, documentati e riusabili dal business. Non basta scrivere SQL corretto: serve che ogni modifica sia tracciabile, verificabile e che porti a decisioni più affidabili. Il segnale che il processo è diventato competenza è sempre lo stesso: sai dire quale decisione cambia, quale dato osservi e quale errore vuoi evitare. Senza quei tre punti, hai una procedura ma non una pratica.

Un modello per restare sull’obiettivo

Fase	Cosa chiarire	Output
Domanda	Quale scelta reale deve migliorare?	Decisione da prendere
Misura	Quale segnale osservabile rappresenta il problema?	Metrica o dato sorgente
Controllo	Quale baseline rende il risultato interpretabile?	Confronto credibile
Azione	Che cosa cambia dopo l’analisi?	Prossimo passo operativo

Lo schema tiene il focus sull’obiettivo: ogni attività tecnica, anche una code review, deve rafforzare almeno uno di questi punti.

Come rendere analizzabile il workflow

Per ragionare sul workflow conviene partire dall’unità di lavoro, che può essere una source, un model, un test, un mart, una metrica o un’esposizione. La leghi a una metrica osservabile come freshness, lineage, copertura dei test, costo del modello o fiducia degli stakeholder, e dichiari la decisione attesa, che riguarda un modello dbt, un semantic layer, un contratto, un test o una pipeline di release. Il rischio costante è scambiare un numero disponibile per una prova sufficiente.

Elemento	Specifica richiesta
Unità di analisi	source, model, test, mart, metrica o esposizione
Segnale principale	freshness, lineage, test coverage, costo modello e fiducia stakeholder
Baseline	Periodo precedente, gruppo comparabile, benchmark o scenario controfattuale
Decisione	modello dbt, semantic layer, contratto, test o pipeline di release
Rischio	Scambiare un numero disponibile per una prova sufficiente

La formalizzazione regge quando un altro analista riprende la stessa logica, ne critica le assunzioni e arriva alla stessa decisione partendo dagli stessi dati.

Caso studio: una PR che tocca tre mart

Una pull request modifica la definizione di is_active_customer e impatta tre mart e due dashboard executive. È il caso che mostra perché la code review deve guardare lineage, ownership, test e comunicazione del cambiamento, non solo se il modello compila. Una modifica innocua in apparenza può spostare un numero su cui un dirigente baserà una scelta.

Evidenza osservata	Lettura prudente	Azione consigliata
Il numero migliora	Potrebbe essere effetto reale o variazione normale	Cercare confronto e segmentazione
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à

Git workflow per progetti dbt

dbt è codice, quindi il branching model che funziona per il software funziona anche per i dati. Il pattern consigliato è trunk-based con feature branch.

main ──────────────────────────────────────────────► (produzione)
  │
  ├── feature/new-mrr-model ──► PR ──► review ──► merge
  │
  ├── fix/campaign-cost-bug ──► PR ──► review ──► merge
  │
  └── staging ──► (deploy automatico su env di test)

Le regole essenziali sono poche e vanno rispettate sempre.

1. Mai commitare direttamente su main: ogni modifica passa da branch e pull request.
2. Ogni PR esegue dbt build su uno schema separato creato dal CI/CD per isolare i cambiamenti.
3. La PR si può mergiare solo se il build è verde e almeno un reviewer ha approvato.
4. Il merge su main fa partire il deploy in produzione o in staging.

Code review per modelli dati

La code review di un modello dbt ha priorità diverse rispetto al codice applicativo. Verifica che i test siano presenti e sufficienti, con almeno un not_null sulla primary key. Controlla che la logica di business stia nel layer corretto, perché regole complesse non vanno nei modelli staging. Assicurati che il naming sia chiaro e coerente con le convenzioni, che ci sia documentazione YAML con descrizioni e test sulle colonne critiche, e che la query regga i volumi di produzione.

In pratica un reviewer scorre una checklist breve: test not_null e unique sulla primary key, logica di business nel layer giusto, naming di file, modello e colonne conforme alle convenzioni, documentazione YAML presente, query scalabile e DAG aciclico.

Gestione dei conflitti su modelli dbt

I conflitti qui sono più rischiosi che altrove, perché Git non interpreta il SQL e non capisce se due modifiche sono compatibili. Per ridurli conviene tenere i modelli piccoli e con una responsabilità singola, così la superficie di conflitto si restringe, e dare a ogni sviluppatore uno schema dedicato tramite i profili, in modo da isolare gli ambienti di lavoro.

my_project:
  target: dev
  outputs:
    dev:
      schema: "dbt_{{ env_var('USER', 'default') }}"

Controllo di qualità

Prima di applicare workflow e code review, verifica completezza, duplicati, timezone, definizioni cambiate e segmenti esclusi. Molte analisi falliscono perché il dato di partenza non rappresenta il comportamento atteso, e nessuna revisione di codice lo recupera.

Interpretazione per segmenti

La media aggregata è solo un punto di partenza. Segmenta per canale, coorte, piano, paese, device e maturità dell’utente. Quando i segmenti si muovono in direzioni opposte, la media inganna e porta a decisioni sbagliate.

Decisione operativa

Ogni analisi deve chiudersi con una scelta concreta, che sia continuare, fermare, iterare, investire, rimuovere o approfondire. Se il workflow e la code review non spostano nessuna decisione, manca il collegamento tra metrica e azione.

Esercizio guidato

Al livello base scrivi una scheda sintetica per il workflow e la code review: decisione da supportare, metrica principale, baseline, rischio e azione prevista. Al livello intermedio costruisci una tabella con tre segmenti o scenari, indicando per ciascuno cosa cambia, una spiegazione alternativa e il controllo che useresti prima di agire. Al livello research-grade prepara un decision memo con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio. Per gli strumenti usa dbt, il warehouse, le sorgenti CRM, gli eventi, i marts, il semantic layer e il lineage; se non hai dati reali, costruisci un dataset sintetico di almeno 200 righe con dimensione temporale, segmenti e metrica di outcome.

L’errore tipico da evitare

Il rischio è usare il workflow e la code review come etichetta invece che come processo. Succede quando si mostra un grafico senza decisione, una metrica senza baseline o una conclusione che non dichiara quali assunzioni potrebbero invalidarla. La domanda chiave resta una: se questo risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca il collegamento tra analisi e azione.

Checkpoint

Prima di chiudere, verifica di saper rispondere a queste domande.

1. Quale decisione concreta dovrebbe migliorare questa lezione?
2. Quale unità di analisi rende il problema misurabile?
3. Quale baseline useresti per evitare una lettura ingenua?
4. Quale errore tipico potrebbe cambiare la conclusione?
5. Quale output consegneresti a uno stakeholder non tecnico?

Riepilogo

Workflow Git e code review servono solo se producono decisioni più chiare e affidabili, non come terminologia. Il percorso problema, modello, formalizzazione, esempio, lab e checkpoint trasforma la lezione in una pratica che puoi verificare.

---

Riferimenti: GitLab Handbook (2024), dbt Labs (2023), Accelerate (Forsgren et al., 2018).