Git workflow, code review, and technical collaboration

Questa lezione appartiene al binario ml-tabellare: qui le tabelle sono il codice che un team modifica insieme, e la domanda è come farlo senza rompere nulla. La risposta sta in un workflow Git disciplinato e in una revisione che guarda i dati, non solo la sintassi.

L’idea in una frase

Il workflow Git applicato a dbt tratta ogni modifica ai modelli come codice revisionato, così nessun numero cambia in produzione senza una pull request testata e approvata. In pratica: i dati si muovono alla velocità della fiducia, non della fretta.

La sequenza da seguire

1. Apri un branch dedicato per ogni modifica e non pubblicare mai direttamente sul ramo principale.
2. Fai eseguire alla pipeline di integrazione la build completa su uno schema isolato per ogni pull request.
3. Richiedi almeno un’approvazione che controlli test, layer della logica, naming e documentazione prima del merge.
4. Unisci solo con build verde e revisione approvata, poi lascia che il merge attivi il deploy.
5. Assegna a ogni sviluppatore uno schema personale, così i test paralleli non si sovrascrivono a vicenda.

Git workflow per progetti dbt

dbt è codice. Il modello di branch che funziona per il software funziona anche per i dati.

Il pattern consigliato è trunk-based con feature branch: una linea principale stabile e branch brevi per ogni modifica.

main ──────────────────────────────────────────────► (production)
  │
  ├── feature/new-mrr-model ──► PR ──► review ──► merge
  │
  ├── fix/campaign-cost-bug ──► PR ──► review ──► merge
  │
  └── staging ──► (automatic deploy to test environment)

Le regole essenziali sono poche e vanno rispettate sempre. Mai pubblicare direttamente su main: ogni modifica passa da branch e pull request. Ogni pull request esegue dbt build su uno schema separato creato dalla pipeline, per isolare i cambiamenti. La pull request si unisce solo se la build è verde e almeno un revisore ha approvato. Il merge su main fa partire il deploy in produzione o in staging.

Code review per modelli dati

La revisione 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 chiave primaria.

Controlla che la logica di business stia nel layer corretto: le regole complesse non vanno nei modelli di staging.

Assicurati che il naming segua le convenzioni e che la documentazione YAML descriva le colonne critiche.

Verifica infine che la query regga i volumi di produzione.

In pratica il revisore scorre una checklist breve: test not_null e unique sulla chiave primaria, logica nel layer giusto, naming conforme, documentazione YAML presente, query scalabile e grafo senza cicli.

Conflitti e ambienti personali

I conflitti qui sono più rischiosi che altrove. Git non interpreta il SQL e non capisce se due modifiche sono compatibili.

Per ridurli, tieni i modelli piccoli con una sola responsabilità: la superficie di conflitto si restringe.

Dai a ogni sviluppatore uno schema dedicato tramite i profili, così i test paralleli non si sovrascrivono.

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

Una pull request che modifica una definizione condivisa come is_active_customer può impattare tre mart e due dashboard direzionali. È il caso che mostra perché la revisione deve guardare lignaggio, ownership, test e comunicazione del cambiamento, non solo il fatto che il modello compili.

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

L’errore che trasforma il processo in etichetta

Il rischio è usare workflow e revisione come etichetta invece che come processo: grafici senza decisione, metriche senza baseline, conclusioni che non dichiarano quali assunzioni potrebbero invalidarle. La cerimonia c’è, ma nessun numero ne esce più solido.

La domanda chiave resta una sola, cioè quale scelta sbaglieresti se questo risultato fosse instabile. Se la revisione non ti aiuta a rispondere, stai solo timbrando ticket.

Verdetto: niente merge senza build verde e revisione approvata; la velocità di un team dati si misura dai rollback evitati, non dalle pull request unite.

Il caso GitHub

GitHub, fondata nel 2008, ha fatto della pull request il rito centrale dello sviluppo collaborativo: proporre, revisionare, discutere e solo poi unire. Nel gennaio 2023 la piattaforma ha superato i 100 milioni di sviluppatori registrati, e quasi tutto il codice open source che conta passa da quel meccanismo di revisione. La stessa disciplina vale per i modelli dati: una definizione condivisa alimenta dashboard usate per decidere e merita la stessa revisione di una libreria. Il riuso senza revisione scala gli errori alla stessa velocità con cui scala il lavoro risparmiato.

Domande per metterti alla prova

1. Cosa deve contenere una pull request su un modello dbt prima di poter essere unita?
2. Quali controlli faresti in revisione oltre al fatto che il modello compili?
3. Perché ogni sviluppatore lavora su uno schema personale e non su quello condiviso?
4. Quando una modifica a una definizione condivisa richiede di avvisare gli altri team?