Perché serve il version control in Fabric

In un progetto di data engineering su Microsoft Fabric convivono notebook, data pipeline, semantic model, lakehouse ed eventhouse che evolvono in parallelo. La Git integration porta questi artefatti sotto controllo di versione, abilitando collaborazione, code review, rollback e tracciabilità delle modifiche. È il primo pilastro di una strategia CI/CD: sincronizza codice e definizioni, non i dati.

Collegare un workspace a Git

La connessione si configura a livello di workspace da Workspace settings → Git integration. Fabric supporta due provider:

  • Azure DevOps (Azure Repos Git): richiede che l’identità sia nello stesso Microsoft Entra ID tenant del workspace. Si selezionano organization, project, repository, branch e una folder (sottocartella) dove serializzare gli item.
  • GitHub / GitHub Enterprise: si autentica con un Personal Access Token.

Ogni workspace punta a un solo branch alla volta. Un item non ancora salvato su Git compare come uncommitted, e la sincronizzazione avviene tramite il pannello Source control.

Il flusso commit / update

  • Commit: promuove le modifiche fatte nel workspace verso il branch Git (workspace → repo).
  • Update: applica al workspace le modifiche presenti su Git (repo → workspace), utile dopo un merge di una pull request o quando un collega ha committato.

L’indicatore di stato mostra quanti item sono cambiati e segnala eventuali conflitti.

Serializzazione degli item

Ogni item supportato viene salvato come una cartella con un file .platform (metadati e logical ID) più i file di definizione specifici. Tra gli item serializzabili: Notebook, Data pipeline, Semantic model (TMDL), Report, Lakehouse (solo metadati e definizione, non i dati delle tabelle), Warehouse, Environment, Eventhouse, KQL Database/Queryset, Eventstream, Dataflow Gen2, Spark Job Definition e Mirrored database. Il set di item supportati si amplia nel tempo: item non supportati semplicemente non vengono tracciati.

Punto chiave d’esame: il version control cattura la definizione dell’oggetto, non il contenuto dati del lakehouse o del warehouse.

Strategie di branching

  • Branch-per-workspace: ogni sviluppatore (o feature) lavora su un proprio workspace isolato collegato al proprio branch. Evita di calpestarsi a vicenda ed è lo scenario tipico di sviluppo parallelo.
  • Branch out to another workspace: da un workspace esistente si crea al volo un nuovo branch e un nuovo workspace già collegato ad esso, ideale per isolare lo sviluppo di una feature. A fine lavoro si apre una pull request verso il branch principale e si sincronizzano gli altri workspace con Update.

Gestione dei conflitti

Un item entra in stato Conflict quando è stato modificato sia nel workspace sia su Git dall’ultima sincronizzazione. Fabric non fa auto-merge dei conflitti: occorre risolverli scegliendo quale versione mantenere (accettare il workspace o accettare Git) direttamente dal pannello Source control, oppure risolvere il merge lato repository prima di fare Update.

Git integration vs deployment pipelines

Sono strumenti complementari, non alternativi:

  • La Git integration governa source control e collaborazione: versioning, branch, pull request, sincronizzazione delle definizioni durante lo sviluppo.
  • Le deployment pipelines governano la promozione tra stage (Development → Test → Production) tra workspace, con confronto item-per-item, deployment rules e parametrizzazione delle connessioni per ogni ambiente.

Il pattern maturo: gli sviluppatori collaborano via Git sul workspace di Development, poi si usano le deployment pipelines (o le Fabric REST API / Azure DevOps pipeline per automazione) per promuovere in Test e Production. Git non “deploya” tra stage; le deployment pipelines non fanno branching né code review.

Trappole tipiche d’esame

  • Scenario: devi versionare notebook e pipeline e abilitare pull request tra sviluppatori → Git integration con Azure DevOps, non deployment pipelines.
  • Scenario: devi promuovere gli artefatti da Test a Production tra workspace diversi → deployment pipelines (con deployment rules), non un semplice commit Git.
  • Scenario: dopo aver collegato Azure DevOps, ti aspetti che i dati del lakehouse finiscano su Git → no, viene serializzata solo la definizione/metadati, mai i dati.
  • Scenario: uno stesso item risulta modificato in workspace e su Git → stato Conflict, da risolvere manualmente; Fabric non fa auto-merge.
  • Scenario: sviluppo isolato di una feature senza toccare il workspace principale → Branch out to another workspace, poi pull request e Update.
  • Scenario: la connessione Azure DevOps fallisce l’autenticazione → verifica che l’account sia nello stesso tenant Microsoft Entra ID del workspace.