Il ciclo di vita analitico in Microsoft Fabric non si gestisce a colpi di export/import: la Git integration collega un workspace a un branch di un repository e rende gli item versionabili come file di definizione. Capire cosa viene versionato, chi può farlo e come si isola il lavoro è materia d’esame ricorrente.

Prerequisiti: senza questi non parte nulla

Requisito Dove si configura Nota operativa
Tenant setting Git attivo Admin portal → Tenant settings Se disabilitato l’opzione “Git integration” non compare affatto nel workspace
Capacity Fabric (non Pro puro) Workspace settings → License info Il branch-out crea un workspace che va assegnato a capacity
Ruolo workspace Admin Manage access Serve per connettere/disconnettere il workspace al repo
Ruolo Member o Contributor Manage access Sufficiente per commit e update, non per la connessione
Permessi sul repo Azure DevOps / GitHub Il permesso Fabric non implica quello Git: servono entrambi

Provider supportati: Azure DevOps (stesso tenant Microsoft Entra ID dell’utente) e GitHub. La connessione lega il workspace a un branch e una cartella del repo: relazione 1:1, non si sincronizzano due branch sullo stesso workspace.

Il flusso operativo

  1. Connect — Workspace settings → Git integration: si scelgono organization, project, repository, branch e directory. Alla connessione Fabric confronta i due lati e mostra lo stato di ogni item.
  2. Commit — gli item con stato Modified o Uncommitted si selezionano e si committano con messaggio. Fabric serializza ogni item in una cartella con i file di definizione (es. .platform, definition.pbir, model.bim/TMDL per il semantic model, .ipynb per i notebook).
  3. Update from Git — porta nel workspace le modifiche committate da altri sul branch. È un’operazione all-or-nothing sugli item selezionabili: non esiste un cherry-pick del singolo item lato Fabric.
  4. Stato item: Synced, Modified, Uncommitted, Conflict, Unsupported.

Conflitti sullo stesso semantic model

Se due sviluppatori modificano lo stesso item — tipicamente un semantic model — e uno committa per primo, il secondo vede stato Conflict all’update. Fabric non fa merge automatico del contenuto: la UI chiede di scegliere la versione del workspace oppure la versione in arrivo da Git per l’intero item. Il merge granulare (riga per riga in TMDL) va fatto fuori da Fabric, in un client Git, su un branch dedicato, e poi ricommittato. Da qui la regola pratica: un item = un owner attivo per volta, oppure branch separati.

Branch out to new workspace

Dal selettore branch nel workspace: Branch out to new workspace crea in un colpo solo un nuovo branch a partire da quello corrente e un nuovo workspace già connesso a quel branch, con gli item sincronizzati. È il pattern raccomandato per il lavoro di feature perché:

  • isola le modifiche: nessun rischio di rompere il workspace di sviluppo condiviso;
  • il branch principale resta sempre in uno stato deployabile;
  • la promozione avviene tramite pull request, quindi con code review e policy del repo, non con un commit diretto;
  • permette di testare la feature su dati/connessioni proprie prima del merge.

Dopo il merge della PR, si torna sul workspace principale e si fa Update from Git. Il workspace di feature va poi eliminato (non resta orfano a consumare capacity).

Git ≠ deployment pipelines. Le deployment pipelines promuovono contenuti tra stage (Dev → Test → Prod) all’interno di Fabric, con deployment rules per riparametrizzare le connessioni. Git gestisce versioning e collaborazione. Il pattern maturo li usa insieme: Git sul workspace di Dev, pipeline per la promozione verso Test e Prod.

Trappole tipiche d’esame

  • Scenario: dopo aver connesso il workspace al repo, le tabelle Delta del lakehouse non compaiono in Git. → Risposta giusta: comportamento atteso. Git versiona solo le definizioni/metadati (incluse shortcut e struttura del lakehouse), mai i dati delle tabelle né i file in OneLake. Per i dati servono altri meccanismi (shortcut, pipeline di copia, mirroring).
  • Scenario: un item resta con stato Unsupported e non è committabile. → Risposta giusta: non tutti gli item type sono versionabili. Non si “forza” il commit: si documenta l’item e lo si ricrea manualmente negli altri ambienti, oppure si attende il supporto.
  • Scenario: un Contributor deve collegare il workspace al repository e riceve errore. → Risposta giusta: serve il ruolo Admin del workspace per connettere/disconnettere, più i permessi sul repo Git. Contributor/Member possono solo commit e update.
  • Scenario: due sviluppatori devono lavorare su feature diverse dello stesso semantic model senza bloccarsi. → Risposta giusta: branch out to new workspace per ciascuno, merge via pull request. Non commit concorrenti sullo stesso branch.
  • Scenario: l’opzione Git integration non appare nelle impostazioni del workspace di nessun utente. → Risposta giusta: verificare il tenant setting nell’admin portal (e la security group abilitata), non i permessi del singolo utente.