Gestire il contenuto di Power BI nel controllo delle versioni

Gli asset riutilizzabili offrono basi coerenti, ma senza il controllo della versione, non è possibile tenere traccia di cosa è cambiato, chi lo ha modificato o quando. Progetti Power BI Desktop e integrazione Git in Fabric portano il controllo del codice sorgente professionale al flusso di lavoro analitico.

Progetti di Power BI Desktop

Un progetto desktop Power BI (.pbip) salva il report e il modello semantico come file di testo normale in una struttura di cartelle anziché un singolo file binario .pbix. La cartella del progetto contiene due sottocartelle principali:

• <nome>. SemanticModel/ contiene la definizione del modello semantico in formato TMDL (Tabular Model Definition Language). TMDL archivia ogni tabella, misura e relazione come file di testo leggibile separato.
• <name>. Report/ contiene la definizione del report nel formato Power BI Report (.pbir). Un .pbir file è un documento JSON che archivia le pagine, gli oggetti visivi e il layout del report come testo strutturato. Questo tipo di file consente il controllo della versione, a differenza .pbix del file archiviato come dati binari.

Poiché ogni definizione è un file di testo, è possibile usare strumenti diff standard per vedere esattamente cosa è cambiato tra le versioni. Una colonna rinominata, una misura DAX modificata o una relazione aggiunta viene visualizzata come modifica di testo non crittografato anziché come differenza binaria.

Per salvare come project, passare a File>Save as in Power BI Desktop e selezionare Power BI Project (pbip) come tipo di file. Power BI Desktop crea la struttura di cartelle e un file .gitignore che esclude i file di impostazioni locali e della cache dal controllo della versione.

Il formato del progetto supporta anche la modifica a livello di codice. Poiché la definizione del modello semantico usa file di testo TMDL, è possibile usare script o strumenti per eseguire aggiornamenti batch. Ad esempio, è possibile aggiungere una descrizione a ogni misura del modello modificando direttamente i file TMDL, quindi eseguendo il commit della modifica batch tramite Git.

Abilitare l'integrazione Git per un'area di lavoro

L'integrazione Git connette un'area di lavoro Fabric a un repository Git in Azure DevOps o GitHub. Le modifiche apportate agli elementi dell'area di lavoro vengono sincronizzate in modo bidirezionale tra l'area di lavoro e il repository. Questa integrazione a livello di area di lavoro consente di controllare tutti gli elementi in un'area di lavoro tramite una singola connessione.

Per configurare l'integrazione di Git:

1. Aprire l'area di lavoro nel portale di Fabric.
2. Selezionare Impostazioni dell'area di lavoro>Integrazione Git.
3. Connettersi al provider Git (Azure DevOps o GitHub).
4. Selezionare il repository, il ramo e la cartella da mappare.
5. Completare la sincronizzazione iniziale per allineare l'area di lavoro al repository.

Dopo aver stabilito la connessione, l'area di lavoro mostra gli indicatori di stato Git per ogni elemento. Gli elementi che differiscono dal repository visualizzano un'icona di modifica. Gli elementi che corrispondono al repository mostrano uno stato sincronizzato.

Usare un'area di lavoro connessa a Git

Una volta connessa l'area di lavoro, si esegue un ciclo di modifica, commit e sincronizzazione:

• Commit: quando si apportano modifiche agli elementi dell'area di lavoro, selezionare Controllo del codice sorgente per esaminare le modifiche in sospeso. Scegliere gli elementi di cui eseguire il commit, fornire un messaggio di commit descrittivo e salvare le modifiche nel repository Git.
• Aggiornamento: quando il repository presenta modifiche più recenti da altri membri del team, selezionare Aggiorna tutto per eseguire il pull di tali modifiche nell'area di lavoro. In questo modo l'area di lavoro viene sincronizzata con lo stato più recente del repository.
• Branch: È possibile spostare l'area di lavoro su un branch diverso per lo sviluppo o il testing. Ogni ramo rappresenta una linea di sviluppo indipendente. Creare rami di funzionalità per le modifiche sperimentali che non devono influire sul ramo principale fino a quando non vengono esaminate.
• Conflitti: se lo stesso elemento è stato modificato sia nell'area di lavoro che nel repository dall'ultima sincronizzazione, Git segnala un conflitto. Per risolvere il conflitto, scegliere la versione da mantenere o unire manualmente le modifiche.

Combinare progetti e integrazione con Git

Progetti Power BI Desktop e integrazione Git di Fabric si completano a vicenda nel flusso di lavoro di un team.

1. Sviluppo locale: gli autori salvano il lavoro come progetti .pbip nel computer locale, usando Power BI Desktop per la creazione e l'iterazione.
2. Commit in Git: autori eseguono il commit di file .pbip nel repository Git condiviso. Il formato basato su testo rende pratiche le revisioni del codice perché i revisori possono vedere esattamente quali misure, colonne o oggetti visivi sono stati modificati.
3. Sincronizzazione dello spazio di lavoro: Lo spazio di lavoro Fabric viene sincronizzato con il repository, quindi il contenuto pubblicato riflette i commit più recenti.

Questo flusso di lavoro offre i vantaggi dello sviluppo locale (iterazione più rapida, lavoro offline) combinato con la cronologia delle versioni centralizzata e la collaborazione tra team tramite Git.

Con gli asset riutilizzabili sotto il controllo della versione, la fase Sviluppo è completa. Passare quindi alla fase Convalida , controllando e verificando i modelli a livello di codice tramite l'endpoint XMLA.