Pianificazione dell'implementazione di Power BI: Sviluppare i contenuti e gestire le modifiche

Nota

Questo articolo fa parte della serie di articoli sulla pianificazione dell'implementazione di Power BI. Questa serie è incentrata principalmente sull'esperienza Power BI in Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

Questo articolo è uno strumento di supporto per lo sviluppo dei contenuti e la gestione delle modifiche come parte della gestione del ciclo di vita del contenuto. È destinato principalmente a:

• Centro di eccellenza (COE) e team BI: team responsabili della supervisione di Power BI nell'organizzazione. Questi team includono decision maker che decidono come gestire il ciclo di vita del contenuto di Power BI. Questi team possono anche includere ruoli come responsabili delle versioni, che gestiscono il ciclo di vita delle versioni del contenuto o tecnici che creano e gestiscono i componenti necessari per usare e supportare in modo efficace la gestione del ciclo di vita.
• Autori di contenuti e proprietari di contenuti: utenti che creano contenuti e che vogliono pubblicarli nel portale di Fabric per condividerli con altri utenti. Questi utenti sono responsabili della gestione del ciclo di vita del contenuto di Power BI creato.

La gestione del ciclo di vita è costituita dai processi e dalle procedure usate per gestire il contenuto dalla creazione al ritiro finale. Nella prima fase della gestione del ciclo di vita si pianificano e progettano contenuti, che implicano la pianificazione della soluzione e il processo decisionale chiave che influiscono sull'approccio alla gestione del ciclo di vita. Nella seconda fase si sviluppano contenuti e si gestiscono le modifiche.

La gestione delle modifiche dei contenuti durante il ciclo di vita è importante per garantire una collaborazione efficace tra creatori di contenuti e una distribuzione stabile e coerente dei contenuti ai fruitori.

L'immagine seguente illustra il ciclo di vita del contenuto di Power BI, evidenziando la fase due, in cui si sviluppano contenuti e si gestiscono le modifiche.

Nota

Per una panoramica della gestione del ciclo di vita dei contenuti, vedere il primo articolo di questa serie.

Suggerimento

Questo articolo è incentrato sulle decisioni e sulle considerazioni principali che consentono di sviluppare contenuti e gestire le modifiche durante il ciclo di vita. Per altre indicazioni su come sviluppare i contenuti e gestire le modifiche, vedere:

• Che cos'è la gestione del ciclo di vita in Microsoft Fabric?: questo articolo fornisce un'introduzione tecnica e un’esercitazione sulle pipeline di integrazione e distribuzione Git di Fabric.
• Procedure consigliate per la gestione del ciclo di vita: questo articolo contiene suggerimenti pratici e linee guida per l'uso delle funzionalità di gestione del ciclo di vita di Fabric e Power BI per sviluppare contenuti e gestire le modifiche.
• Integrazione di OneDrive e SharePoint con Power BI Desktop: questo articolo contiene una panoramica delle opzioni per usare e archiviare i file salvati in OneDrive per le aziende e gli istituti di istruzione o SharePoint quando si esegue il controllo della versione con file .pbix.
• Introduzione a Git in Azure Repos: questa serie di articoli contiene suggerimenti pratici, esercitazioni e indicazioni per eseguire il controllo del codice sorgente usando un repository Git in Azure Repos.

I creatori e i proprietari di contenuti devono gestire le modifiche dei contenuti usando il controllo della versione. Il controllo della versione è la pratica di gestire le modifiche apportate ai file o al codice in un repository centrale. Questa pratica facilita una collaborazione e una gestione dei contenuti più efficace.

Tra gli altri vantaggi del controllo della versione c’è la possibilità di:

• Unire le modifiche da parte di più autori di contenuti e gestire i conflitti di unione.
• Identificare il contenuto modificato e le modifiche apportate a tale contenuto.
• Collegare le modifiche del contenuto a elementi di lavoro specifici.
• Raggruppare le modifiche in versioni distinte con la cronologia delle versioni.
• Eseguire il rollback delle modifiche o dell'intera versione del contenuto.

Suggerimento

È consigliabile usare il controllo della versione per tutti i contenuti creati, se possibile. L'uso del controllo della versione offre vantaggi significativi sia per i creatori di contenuti che per i fruitori e riduce il rischio di interruzioni a causa della perdita di file o dell'impossibilità di eseguire il rollback delle modifiche.

Il primo passaggio per configurare il controllo della versione consiste nel decidere come sviluppare i contenuti.

Decidere come sviluppare i contenuti

A seconda del modo in cui vengono creati i contenuti, si dovranno prendere decisioni diverse su come gestirlo. Ad esempio, per i report e i modelli semantici di Power BI, un file di Power BI Desktop (.pbix) ha meno opzioni per il controllo della versione rispetto al formato di progetto di Power BI Desktop (.pbip). Questo perché un file con estensione pbix è un formato binario, mentre il formato pbip contiene contenuti e metadati leggibili e basati su testo. La presenza di contenuti e metadati leggibili consente di tenere traccia più facilmente delle modifiche di modelli e report usando il controllo del codice sorgente. Il controllo del codice sorgente si verifica quando si visualizzano e gestiscono le modifiche all'interno del contenuto nel codice e nei metadati.

Suggerimento

Quando si sviluppano modelli semantici e report con Power BI Desktop, è consigliabile usare file con estensione pbip anziché pbix. Quando si sviluppano modelli semantici usando gli strumenti XMLA, è consigliabile usare il formato TMDL (Tabular Model Definition Language), anziché i file bim.

I formati .pbip e TMDL supportano il rilevamento e l'unione semplificata delle modifiche a livello di oggetto. Ciò significa che è possibile visualizzare e gestire le modifiche ai singoli oggetti, ad esempio misure o tabelle DAX.

Power BI Desktop

È possibile usare Power BI Desktop per creare modelli semantici o report, che è possibile salvare come file .pbix o .pbip. Quando si usa Power BI Desktop, è possibile usare altri file di contenuto personalizzati.Quando si usa Power BI Desktop per creare contenuti, alcune decisioni chiave da prendere riguardano:

• Quale formato di file da usare: è possibile salvare il contenuto come file .pbix o .pbip. Ad esempio, l'integrazione Git richiede l'uso di file .pbip, i creatori self-service potrebbero trovare più semplice gestire file con estensione pbix in Teams, SharePoint o OneDrive.
• Come gestire i contenuti personalizzati: è possibile aggiungere temi, oggetti visivi personalizzati o immagini ai file di Power BI Desktop, che possono richiedere considerazioni distinte per la gestione del ciclo di vita. Ad esempio, quando i creatori di contenuti creano oggetti visivi personalizzati, devono salvare e gestire la definizione dell’oggetto visivo in un file separato.
• Come gestire le funzionalità di anteprima: è possibile acconsentire esplicitamente alle funzionalità o alle impostazioni di anteprima in Power BI Desktop, il che modifica il contenuto e il modo in cui usarlo. Ad esempio, è possibile eseguire passaggi aggiuntivi per convalidare il contenuto che usa le funzionalità di anteprima.

Creazione Web

Alcuni contenuti, ad esempio flussi di dati, dashboard e scorecard, possono essere creati solo nel portale di Fabric. Inoltre è possibile creare o modificare alcuni contenuti, ad esempio modelli semantici, report e report impaginati, sia nel portale di Fabric che usando gli strumenti locali. Quando si crea contenuto usando la creazione Web, è necessario prendere alcune decisioni chiave:

• Come gestire le modifiche: è possibile apportare modifiche a molti tipi di elementi usando la creazione Web, ma queste modifiche potrebbero essere salvate immediatamente, sovrascrivendo le versioni precedenti. Ad esempio, se si collabora con altri utenti, si potrebbe voler evitare la creazione Web su elementi condivisi, lavorando invece sulla propria copia.
• Come recuperare i backup del contenuto: è possibile creare contenuto come report o modelli semantici usando la creazione Web, ma questi elementi non possono essere scaricati nei file con estensione pbix locali. Ad esempio, è possibile scegliere di eseguire il backup di questo contenuto recuperando e archiviando i relativi metadati.

Suggerimento

Quando si sviluppano flussi di dati e scorecard, è consigliabile recuperare le definizioni degli elementi per gestire le modifiche e archiviare un backup. È possibile automatizzare il recupero del flusso di dati e delle scorecard usando le API REST di Fabric. In particolare, è possibile usare rispettivamente gli endpoint Get Dataflow e Get Scorecards.

Attenzione

Alcuni contenuti, ad esempio i dashboard, non hanno la possibilità di recuperare una definizione. Per questo contenuto, non è possibile tenere facilmente traccia delle modifiche o recuperare un backup.

Altri strumenti

È possibile usare altri strumenti per creare o gestire determinati tipi di contenuto. Questi strumenti possono offrire vantaggi aggiuntivi, adattarsi meglio al flusso di lavoro o essere necessari per gestire funzionalità o tipi di contenuto specifici. È possibile usare sia altri strumenti Microsoft che strumenti di terze parti per creare e gestire il contenuto. Di seguito sono riportati altri strumenti che è possibile usare per creare o gestire il contenuto.

• Visual Studio o Visual Studio Code: un ambiente di sviluppo integrato che consente agli sviluppatori di creare e gestire modelli semantici o notebook di Fabric. Con Visual Studio e Visual Studio Code, gli sviluppatori possono anche eseguire la gestione del controllo del codice sorgente eseguendo il commit e il push delle modifiche locali in un repository remoto.
• Editor tabulare: strumento di terze parti per sviluppare e gestire modelli semantici.
• Excel: strumento client per tabelle pivot e tabelle connesse live che funzionano con un modello semantico.
• Power BI Report Builder: applicazione desktop per la creazione di file di report impaginati (con estensione rdl).

Quando si crea contenuto usando altri strumenti, è necessario prendere alcune decisioni chiave:

• Come gestire le licenze: altri strumenti possono richiedere licenze aggiuntive da gestire.
• Come pubblicare contenuto: altri strumenti possono richiedere passaggi aggiuntivi per pubblicare contenuto, ad esempio usando endpoint XMLA o le API REST di Power BI.

Dopo aver deciso come si creerà il contenuto, sarà necessario scegliere dove pubblicare e testare il contenuto durante lo sviluppo.

Decidere come configurare e usare le aree di lavoro

Quando si sviluppa contenuto, è necessario usare più aree di lavoro (o fasi) per separare il contenuto di produzione usato dall'organizzazione dal contenuto sviluppato o convalidato. Esistono diversi vantaggi nell'uso di aree di lavoro separate per il contenuto:

• È possibile sviluppare e testare il contenuto senza influire sul contenuto attualmente in uso. In questo modo si evitano modifiche che possono causare interruzioni involontarie del contenuto nell'ambiente di produzione.
• È possibile usare risorse separate per lo sviluppo e il test del contenuto, ad esempio usando gateway dati separati o capacità Fabric. In questo modo si evita che le risorse usate per lo sviluppo e il test interrompano i carichi di lavoro di produzione, causando aggiornamenti dati o report lenti.
• È possibile creare un processo più strutturato per sviluppare, testare e rilasciare contenuto predisponendo ambienti discreti per ognuna di queste fasi. Ciò consente di migliorare la produttività.

In Fabric e Power BI è consigliabile usare aree di lavoro Fabric separate, come descritto negli articoli sulla pianificazione a livello di tenant e a livello di area di lavoro.

Importante

L'uso di ambienti separati è un passaggio essenziale per garantire il successo dell'approccio alla gestione del ciclo di vita del contenuto.

Esistono diversi modi per usare le aree di lavoro di Fabric per separare gli ambienti. In genere, oltre all'ambiente locale, si usano due o più aree di lavoro per gestire il contenuto durante il ciclo di vita.

Rispondere alle domande seguenti durante la pianificazione dell'uso di aree di lavoro separate per tutto il ciclo di vita di questo contenuto:

• Quante aree di lavoro sono necessarie?
• Le aree di lavoro verranno separate in base al tipo di elemento?
• Chi avrà accesso a ogni area di lavoro?
• Le aree di lavoro appartengono a una pipeline di distribuzione di Fabric oppure si orchestra la distribuzione usando altri approcci, ad esempio tramite Azure Pipelines?
• Come si gestirà la pubblicazione tra aree di lavoro? Ad esempio, è necessario assicurarsi che i report in un'area di lavoro di test per i report si connettano a modelli semantici in un'area di lavoro di test separata per gli elementi dati?
• È necessario usare anche risorse di supporto separate per gli elementi nelle aree di lavoro di produzione, ad esempio un cluster gateway dati locale separato?

Le sezioni seguenti offrono una panoramica generale dei diversi approcci che è possibile adottare per separare le aree di lavoro e facilitare la gestione del ciclo di vita.

Nota

Le sezioni seguenti illustrano come configurare e usare aree di lavoro separate. È possibile distribuire il contenuto in queste aree di lavoro usando uno dei quattro approcci seguenti:

• Pubblicazione da Power BI Desktop.
• Distribuzione del contenuto di un'altra area di lavoro tramite le pipeline di distribuzione di Fabric.
• Sincronizzazione del contenuto da un repository Git remoto tramite l'integrazione Git.
• Distribuzione del contenuto a livello di programmazione tramite le API REST di Fabric, le API REST di Power BI o gli endpoint XMLA.

Per altre informazioni su questi approcci per distribuire il contenuto, vedere Fase 4: Distribuire il contenuto più avanti in questa serie.

Aree di lavoro di test e produzione

Quando si distribuisce contenuto più semplice non critico per l'organizzazione, spesso due aree di lavoro possono essere sufficienti. In questo scenario, i creatori di contenuti hanno in genere una collaborazione limitata sugli stessi elementi e sviluppano contenuto in locale.

Il diagramma seguente illustra un esempio generale di come usare ambienti separati con una sola area di lavoro di test e produzione.

Il diagramma illustra i processi e i componenti seguenti per separare le aree di lavoro in questo approccio.

Articolo	Descrizione
	I creatori di contenuti sviluppano contenuti nell'ambiente locale.
	Quando sono pronti, i creatori di contenuti pubblicano il contenuto in un'area di lavoro di test. I creatori di contenuti possono sviluppare contenuti che possono essere prodotti solo con la creazione Web ed eseguire la convalida del contenuto nell'area di lavoro di test.
	Quando sono pronti, i creatori di contenuti distribuiscono il contenuto in un'area di lavoro di produzione. Nell'area di lavoro di produzione i creatori di contenuti distribuiscono il contenuto pubblicando un'app Power BI o condividendo il contenuto dall'area di lavoro.

Nota

Esistono molti modi diversi per configurare e usare aree di lavoro separate e distribuire il contenuto tra queste aree di lavoro. È tuttavia consigliabile non eseguire lo sviluppo locale, quindi pubblicare il contenuto direttamente in un'area di lavoro di produzione. Ciò può causare interruzioni e errori evitabili.

Aree di lavoro di sviluppo, test e produzione

Quando si distribuisce contenuto critico, in genere si usano tre o più aree di lavoro separate. In questo scenario, i creatori di contenuti spesso collaborano in un'area di lavoro di sviluppo aggiuntiva che contiene la versione più recente della soluzione.

Il diagramma seguente illustra un esempio generale di come usare ambienti separati con un'area di lavoro di sviluppo, test e produzione.

Il diagramma illustra i processi e i componenti seguenti per separare le aree di lavoro in questo approccio.

Articolo	Descrizione
	I creatori di contenuti sviluppano contenuti nell'ambiente locale.
	Quando sono pronti, i creatori di contenuti pubblicano il contenuto in un'area di lavoro di sviluppo. Nell'area di lavoro sviluppo i creatori di contenuti possono sviluppare contenuti che possono essere prodotti solo con la creazione Web. I creatori di contenuti possono anche convalidare il contenuto nell'area di lavoro di sviluppo.
	Quando sono pronti, i creatori di contenuti distribuiscono il contenuto in un'area di lavoro di test. Nell'area di lavoro di test, gli utenti convalidano i contenuti nell'area di lavoro o in un'app.
	Quando sono pronti, i creatori di contenuti distribuiscono il contenuto in un'area di lavoro di produzione. Nell'area di lavoro di produzione i creatori di contenuti distribuiscono il contenuto pubblicando un'app Power BI o condividendo il contenuto dall'area di lavoro.

Nota

È possibile usare fino a dieci ambienti diversi con pipeline di distribuzione. Ad esempio, potrebbe essere necessario avere un ambiente di pre-produzione tra test e produzione specifico per tipi speciali di convalida, ad esempio i test delle prestazioni.

Area di lavoro privata con integrazione Git

Quando si distribuisce contenuto critico, ogni sviluppatore può usare anche la propria area di lavoro privata per lo sviluppo. In questo scenario, un'area di lavoro privata consente ai creatori di contenuti di testare il contenuto nel portale di Fabric o di usare funzionalità come l'aggiornamento pianificato senza rischiare interruzioni per altri utenti del team di sviluppo. I creatori di contenuti possono sviluppare contenuto anche nel portale di Fabric, ad esempio flussi di dati. Le aree di lavoro private possono essere una scelta ottimale quando si gestiscono le modifiche al contenuto usando l'integrazione Git insieme ad Azure DevOps.

Nota

Azure DevOps è una suite di servizi che si integrano con Power BI e Fabric per pianificare e orchestrare la gestione del ciclo di vita dei contenuti. Quando si usa Azure DevOps in questo modo, si sfruttano in genere i servizi seguenti:

• Azure Repos: consente di creare e usare un repository Git remoto, ovvero una posizione di archiviazione remota usata per tenere traccia e gestire le modifiche del contenuto.
• Azure Pipelines: consente di creare e usare un set di attività automatizzate per gestire, testare e distribuire contenuto da un repository remoto a un'area di lavoro.
• Azure Test Plans: consente di progettare test per convalidare la soluzione e automatizzare il controllo qualità insieme ad Azure Pipelines.
• Azure Boards: consente di usare le bacheche per tenere traccia delle attività e dei piani come elementi di lavoro e collegare o fare riferimento agli elementi di lavoro di altri servizi Azure DevOps.
• Wiki di Azure: consente di condividere informazioni con il proprio team per comprendere e contribuire al contenuto.

Il diagramma seguente illustra un esempio generale di come usare ambienti separati usando un'area di lavoro privata con l'integrazione Git.

Nota

Il diagramma illustra diversi sviluppatori che lavorano su rami separati di una soluzione (ramo 1 e ramo 2) prima di unire le modifiche in un ramo principale. Si tratta della rappresentazione semplificata di una strategia di ramificazione Git per illustrare il modo in cui gli sviluppatori possono integrare le modifiche con un repository Git remoto e trarre vantaggio dall'integrazione Git in Fabric.

Il diagramma illustra i processi e i componenti seguenti per separare le aree di lavoro in questo approccio.

Articolo	Descrizione
	Ogni creatore di contenuti sviluppa contenuti nel proprio ambiente locale.
	Quando sono pronti, i creatori di contenuti eseguono il commit e il push delle modifiche in un repository remoto, ad esempio un repository Git di Azure Repos.
	Nel repository Git remoto, i creatori di contenuti tengono traccia e gestiscono le modifiche del contenuto usando il controllo del codice sorgente e creano un ramo e uniscono il contenuto per facilitare la collaborazione.
	I creatori di contenuti sincronizzano un ramo del repository remoto con un'area di lavoro privata. Dopo la sincronizzazione, le modifiche più recenti di cui un autore esegue il commit e il push nel ramo sono visibili nell'area di lavoro privata. I diversi creatori di contenuti lavorano autonomamente, separando i rami man mano che apportano modifiche.
	Nelle aree di lavoro private, i creatori di contenuti possono sviluppare contenuti usando la creazione Web e convalidare le proprie modifiche. Le modifiche al contenuto apportate dalla creazione Web possono essere sincronizzate con il ramo nel repository Git quando l'autore del contenuto esegue il commit e il push di queste modifiche dall'area di lavoro. I diversi creatori di contenuti lavorano in aree di lavoro private personalizzate e separate.
	Quando sono pronti, i creatori di contenuti eseguono una richiesta pull per unire le modifiche nel ramo principale della soluzione.
	Dopo l'unione delle modifiche, il ramo principale viene sincronizzato con l'area di lavoro di sviluppo.
	Nell'area di lavoro sviluppo, i creatori di contenuti possono sviluppare contenuto non supportato dall'integrazione Git di Fabric, ad esempio i dashboard. I creatori di contenuti convalidano anche la soluzione integrata che contiene tutte le modifiche più recenti.
	Quando sono pronti, i creatori di contenuti distribuiscono il contenuto in un'area di lavoro di test. Nell'area di lavoro di test gli utenti eseguono test di accettazione utente del contenuto.
	Quando sono pronti, i creatori di contenuti distribuiscono il contenuto in un'area di lavoro di produzione. Nell'area di lavoro di produzione i creatori di contenuti distribuiscono il contenuto pubblicando un'app Power BI o condividendo il contenuto dall'area di lavoro.

Risorse di supporto per le aree di lavoro

Quando si usano ambienti separati, è consigliabile considerare anche in che modo ciò influisce sulle varie risorse di supporto usate in questi ambienti. Per queste risorse di supporto, valutare se è necessario separarle anche nello stesso numero di fasi o in che modo coordinarne l'uso in questi ambienti.

• Gateway: prendere in considerazione l'uso di cluster gateway dati locali separati e gateway di rete virtuale per i carichi di lavoro di produzione. Ciò è utile per evitare interruzioni, ma anche per garantire tempi di attività quando è necessario aggiornare questi gateway.
• App: è consigliabile avere app separate per le aree di lavoro di test e produzione. Non è possibile distribuire o copiare app tra le fasi. Le app nell'area di lavoro di test consentono di testare il contenuto e l'esperienza dell'app prima di distribuire le modifiche nell'area di lavoro di produzione. Le app nell'area di lavoro di produzione sono destinate a distribuire contenuti agli utenti finali in un'esperienza strutturata.
• Azure DevOps: se si intende usare Azure DevOps per collaborare e orchestrare il controllo del codice sorgente e la distribuzione, valutare come usare rami e Azure Pipelines per distribuire il contenuto tra questi ambienti. Per altre informazioni sull'uso di Azure Pipelines per distribuire il contenuto, vedere Fase 4: Distribuire il contenuto.

Dopo aver deciso come configurare e usare le aree di lavoro, il passaggio successivo consiste nel decidere come eseguire il controllo della versione per tenere traccia e gestire le modifiche del contenuto.

Decidere come usare il controllo della versione

In Power BI è possibile eseguire il controllo della versione usando SharePoint/OneDrive o un repository Git remoto, ad esempio Azure Repos, che è un componente di Azure DevOps. In entrambi gli approcci si aggiungono file di contenuto locali a una posizione di archiviazione remota per tenere traccia e gestire le modifiche. È consigliabile usare SharePoint o OneDrive solo per progetti più piccoli e più semplici, poiché non dispone delle funzionalità e dell'affidabilità necessaria per supportare scenari più grandi o più complessi.

Ecco alcune considerazioni generali che consentono di configurare e usare il controllo della versione.

• Avvisi: è necessario configurare avvisi per il momento in cui altri utenti aggiungono, rimuovono o modificano file critici.
• Ambito: definire chiaramente l'ambito della posizione di archiviazione remota. Idealmente, l'ambito della posizione di archiviazione remota è identico all'ambito delle aree di lavoro downstream e delle app usate per distribuire contenuto ai consumer.
• Accesso: è necessario configurare l'accesso alla posizione di archiviazione remota usando un modello di autorizzazioni simile configurato per le autorizzazioni della pipeline di distribuzione e i ruoli dell'area di lavoro. Gli autori di contenuti devono accedere alla posizione di archiviazione remota.
• Documentazione: aggiungere file di testo alla posizione di archiviazione remota per descrivere la posizione di archiviazione remota e i relativi scopi, la proprietà, l’accesso e i processi definiti.

Le sezioni seguenti descrivono ogni approccio e le considerazioni chiave per decidere quale usare.

Controllo della versione tramite SharePoint o OneDrive per le aziende e gli istituti di istruzione

SharePoint dispone del controllo della versione predefinito per i file. I creatori di contenuti possono sviluppare modelli semantici o report in locale, e le relative modifiche vengono sincronizzate con una raccolta documenti di SharePoint o OneDrive per le aziende e gli istituti di istruzione.

Suggerimento

Usare SharePoint o OneDrive per il controllo della versione solo in scenari più semplici e più piccoli, come la pubblicazione di contenuti self-service. Per scenari più grandi o più complessi, è consigliabile eseguire il controllo del codice sorgente usando un repository Git remoto.

Il diagramma seguente illustra una panoramica generale della modalità di esecuzione del controllo della versione tramite SharePoint o OneDrive.

Il diagramma descrive i processi e i componenti seguenti.

Articolo	Descrizione
	I creatori di contenuti sviluppano modelli semantici e report nell'ambiente locale e salvano questi modelli e report come file .pbix.
	Quando sono pronti, i creatori di contenuti salvano le modifiche, che sincronizzano con una raccolta remota di SharePoint o OneDrive per le aziende e gli istituti di istruzione.
	Nella raccolta remota i creatori di contenuti tengono traccia delle modifiche a livello di file che facilitano il controllo della versione.
	I creatori di contenuti possono collegare un modello semantico pubblicato o un report a un file con estensione pbix per facilitare l'aggiornamento di OneDrive. L'aggiornamento di OneDrive pubblica automaticamente le modifiche al contenuto ogni ora.
	Nell'area di lavoro Fabric i creatori di contenuti visualizzano le modifiche apportate al contenuto di Power BI al termine dell'aggiornamento di OneDrive.

Importante

È possibile eseguire il controllo della versione solo usando i file di SharePoint o OneDrive per Power BI Desktop che contengono modelli o report semantici. Non è possibile eseguire facilmente il controllo della versione usando SharePoint o OneDrive per altri tipi di elementi di Power BI, come i flussi di dati, o per tipi di elementi Fabric come i notebook. Per questi tipi di elementi, è consigliabile eseguire il controllo della versione usando un repository Git remoto, ad esempio Azure Repos.

Per riepilogare, i creatori di contenuti possono collegare un modello semantico pubblicato o un report a un file con estensione pbix archiviato in una raccolta di SharePoint o OneDrive per le aziende e gli istituti di istruzione. Con questo approccio, i creatori di contenuti non devono più pubblicare il modello semantico per visualizzare le modifiche. Le modifiche sono invece visibili dopo un aggiornamento automatico di OneDrive, che avviene ogni ora. Anche se pratico, questo approccio presuppone alcune considerazioni e non si può facilmente tornare indietro.

Sebbene sia facile da configurare e da gestire, il controllo della versione con SharePoint o OneDrive presenta più limitazioni. Ad esempio, non è possibile visualizzare le modifiche all'interno del contenuto e non è nemmeno possibile confrontare le versioni. Inoltre, non è possibile configurare processi più sofisticati per gestire queste modifiche, ad esempio le richieste di ramificazione o pull, descritte più avanti in questo articolo.

Prendere in considerazione l'uso di SharePoint o OneDrive per tenere traccia e gestire le modifiche negli scenari seguenti:

• Il contenuto è costituito solo da modelli semantici o report salvati come file .pbix.
• Gli utenti self-service creano e gestiscono il contenuto.
• I creatori di contenuti collaborano usando Microsoft Teams.
• I creatori di contenuti non hanno esperienza con Git e con la gestione del controllo del codice sorgente.
• I creatori di contenuti gestiscono un singolo elemento con complessità e collaborazione limitate.
• I file con estensione pbix hanno un'etichetta di riservatezza che ne crittografa il contenuto.

Nota

OneDrive e SharePoint supportano il contenuto con etichette di riservatezza, ad eccezione di alcuni scenari limitati. Al contrario, l'integrazione Git con Fabric non supporta le etichette di riservatezza.

Evitare di usare SharePoint o OneDrive per tenere traccia e gestire le modifiche negli scenari seguenti:

• Il contenuto è costituito da tipi di elementi diversi da modelli semantici e report.
• Il contenuto è complesso o di grandi dimensioni nell'ambito.
• I creatori di contenuti devono lavorare in modo collaborativo sullo stesso elemento contemporaneamente.

Le sezioni seguenti descrivono considerazioni aggiuntive per l'uso efficace del controllo della versione tramite SharePoint o OneDrive con Power BI.

Integrazione di Microsoft Teams

È possibile usare le raccolte documenti di Microsoft Teams se i creatori di contenuti lo usano per la collaborazione. Le raccolte documenti sono siti di SharePoint e l’uso di raccolte documenti (anziché di un sito di SharePoint separato o una cartella di OneDrive) garantisce la centralizzazione di contenuto, file e collaborazione.

Sincronizzare ed estrarre i file

È consigliabile estrarre i file su cui si sta lavorando per evitare possibili conflitti di modifica. Al termine delle modifiche, sincronizzare i file con commenti che descrivono la modifica. La sincronizzazione e l'estrazione dei file consente di migliorare la collaborazione tra creatori di contenuti quando si usa SharePoint o OneDrive per le aziende e gli istituti di istruzione per il controllo della versione. Se si sincronizzano e archiviano file con più creatori di contenuti, è possibile modificare la raccolta siti di SharePoint per visualizzare l'ultimo aggiornamento e i commenti dell'ultima sincronizzazione.

Cronologia delle versioni

Assicurarsi di eseguire il backup del contenuto in una posizione separata in caso di interruzioni impreviste nella raccolta documenti del sito di SharePoint. È inoltre consigliabile impostare dei limiti al numero di versioni mantenute nel sito di SharePoint ed eliminare le versioni precedenti. In questo modo, la cronologia delle versioni rimane significativa e non occupa troppo spazio.

Per un controllo della versione più sofisticato, è possibile archiviare i file in un repository remoto come Azure Repos e gestire le modifiche usando il controllo del codice sorgente.

Controllo del codice sorgente tramite un repository Git remoto

Un repository Git remoto facilita il controllo del codice sorgente dei file, il che offre ai creatori di contenuti più opzioni per tenere traccia e gestire le modifiche. In breve, i creatori di contenuti possono sviluppare contenuti in locale o nel servizio Power BI, quindi eseguire il commit e il push di tali modifiche in un repository Git remoto come Azure Repos

Nota

È inoltre possibile eseguire il controllo del codice sorgente del contenuto senza usare l'integrazione Git. In questo scenario, è comunque possibile tenere traccia e gestire le modifiche al contenuto in un repository Git remoto, ma si distribuisce il contenuto usando le API REST o gli endpoint di lettura/scrittura XMLA. Per altre informazioni su questi metodi di distribuzione del contenuto, vedere Fase 4: Distribuire il contenuto.

Il diagramma seguente illustra una panoramica generale del modo in cui si esegue il controllo del codice sorgente tramite

Il diagramma descrive i processi e i componenti seguenti.

Articolo	Descrizione
	I creatori di contenuti sviluppano modelli semantici e report nell'ambiente locale e salvano questi modelli e report come file .pbip. I creatori di contenuti possono anche sviluppare modelli semantici e salvare i metadati del modello.
	Quando sono pronti, i creatori di contenuti salvano le modifiche, di cui eseguono il commit e il push in un repository Git remoto a intervalli regolari.
	Nel repository Git remoto i creatori di contenuti tengono traccia delle modifiche a livello di oggetto, il che facilita il controllo della versione. I creatori di contenuti possono anche creare rami per lavorare sul contenuto e unire le modifiche in un singolo ramo usando le richieste pull.
	I creatori di contenuti possono sincronizzare il contenuto dal repository remoto usando l'integrazione Git. Possono anche distribuire contenuto usando altri approcci, ad esempio Azure Pipelines insieme alle API REST.
	Nell'area di lavoro Fabric i creatori di contenuti visualizzano le modifiche apportate al contenuto di Power BI al termine della sincronizzazione o della distribuzione. I creatori di contenuti possono creare contenuti come flussi di dati o notebook nell'area di lavoro. Se usano l'integrazione Git, i creatori di contenuti collegano questa area di lavoro a un ramo specifico del repository remoto.
	I creatori di contenuti possono eseguire il commit e il push delle modifiche da un'area di lavoro al repository remoto usando l'integrazione Git. Queste modifiche possono importare definizioni di elementi per il contenuto supportato creato nell'area di lavoro, ad esempio flussi di dati e notebook.

In sintesi, i creatori di contenuti archiviano file con estensione pbip, file di metadati e documentazione in un repository remoto di Azure Repos centrale. Questi file sono curati da un proprietario tecnico. Mentre un creatore di contenuti sviluppa una soluzione, un proprietario tecnico è responsabile della gestione della soluzione e della revisione delle modifiche, nonché dell'unione in un'unica soluzione. Azure Repos offre opzioni per tenere traccia e gestire le modifiche più sofisticate rispetto a SharePoint e OneDrive. La gestione di un repository ben curato e documentato è essenziale perché è alla base dell'intero contenuto e collaborazione.

Prendere in considerazione l'uso del controllo del codice sorgente per tenere traccia e gestire le modifiche negli scenari seguenti:

• I team centralizzati o decentralizzati creano e gestiscono il contenuto.
• I creatori di contenuti collaborano usando Azure DevOps.
• I creatori di contenuti hanno familiarità con Git, la gestione del controllo del codice sorgente o i principi DataOps.
• I creatori di contenuti gestiscono contenuti complessi o importanti o prevedono che il contenuto venga ridimensionato e acquisisca complessità e importanza.

Ecco alcuni prerequisiti e considerazioni che consentono di usare in modo efficace il controllo del codice sorgente con Azure DevOps.

• Git: per eseguire il commit e il push delle modifiche in un repository remoto, i creatori di contenuti devono scaricare e installare Git. Git è un sistema di controllo della versione distribuito che tiene traccia delle modifiche apportate ai file. Per informazioni di base su Git, vedere Informazioni su Git.
• Strumenti: per usare Git, i creatori di contenuti devono usare un'interfaccia della riga di comando (CLI) o un client dell'interfaccia utente grafica (GUI) per SCM, ad esempio Visual Studio o Visual Studio Code.
• Licenze e autorizzazioni: per creare e usare un repository Git Azure Repos, i creatori di contenuti devono avere le seguenti caratteristiche:
  • Livello di accesso impostato su Basic (anziché Stakeholder).
  • Appartenere a un'organizzazione e a un progetto.
  • Autorizzazioni appropriate per il repository.
• Integrazione Git con Fabric: per sincronizzare il contenuto in un repository remoto con un'area di lavoro di Microsoft Fabric, i creatori di contenuti usano l’integrazione Git con Fabric. Questo aspetto è importante per tenere traccia e gestire le modifiche apportate al contenuto creato nel portale di Fabric, ad esempio i flussi di dati.

Suggerimento

Per facilitare il controllo del codice sorgente con lo sviluppo locale, è consigliabile usare un'applicazione client come Visual Studio Code. Si usa Power BI Desktop per sviluppare contenuto, quindi è possibile usare Visual Studio Code per eseguire la gestione del controllo del codice sorgente del contenuto, eseguendo lo staging, il commit e il push delle modifiche nel repository remoto.

Avviso

L'integrazione Git con Fabric presenta alcune limitazioni con gli elementi e gli scenari supportati. Assicurarsi di verificare prima di tutto se l'integrazione Git di Fabric è più adatta allo scenario specifico o se adottare un approccio diverso per implementare il controllo del codice sorgente.

Inoltre, le etichette di riservatezza non sono supportate con l'integrazione Git per Fabric e l’esportazione di elementi con etichette di riservatezza potrebbe essere disabilitata. Se il contenuto ha etichette di riservatezza, è consigliabile pianificare come ottenere il controllo della versione pur rispettando i criteri di prevenzione della perdita dei dati.

Un vantaggio fondamentale dell'uso del controllo del codice sorgente con Azure Repos è una migliore collaborazione tra creatori di contenuti e una maggiore personalizzazione e supervisione riguardo alle modifiche e alla distribuzione del contenuto.

Il diagramma seguente illustra una panoramica generale del modo in cui Azure DevOps consente la collaborazione sul controllo del codice sorgente.

Nota

Il diagramma precedente illustra un esempio di come collaborare usando Azure DevOps. Scegliere un approccio più adatto alle esigenze e al modo di lavorare del team.

Il diagramma illustra le azioni utente, i processi e le funzionalità seguenti.

Articolo	Descrizione
	Un autore di contenuti crea un nuovo ramo di breve durata clonando il ramo principale, che contiene la versione più recente del contenuto. Il nuovo ramo viene spesso definito ramo di funzionalità, perché viene usato per sviluppare una funzionalità specifica o risolvere un problema specifico.
	L'autore del contenuto esegue il commit delle modifiche in un repository locale durante lo sviluppo.
	L'autore del contenuto collega le modifiche agli elementi di lavoro gestiti in Azure Boards. Gli elementi di lavoro descrivono sviluppi, miglioramenti o correzioni di bug specifici con ambito nel ramo.
	L'autore del contenuto esegue regolarmente il commit delle modifiche. Quando è pronto, l'autore del contenuto pubblica il ramo nel repository remoto.
	Per testare le modifiche, l'autore del contenuto distribuisce la propria soluzione in un'area di lavoro isolata per lo sviluppo (non illustrata in questo diagramma). L'autore del contenuto può anche sincronizzare il ramo di funzionalità nell'area di lavoro usando l'integrazione Git di Fabric.
	Gli autori di contenuti e i proprietari di contenuti documentano la soluzione e i relativi processi in un Wiki di Azure, disponibile per l'intero team di sviluppo.
	Quando è pronto, l'autore del contenuto apre una richiesta pull per unire il ramo di funzionalità nel ramo principale.
	Un proprietario tecnico è responsabile della revisione della richiesta pull e dell'unione delle modifiche. Quando approvano la richiesta pull, uniscono il ramo di funzionalità nel ramo principale.
	Un'operazione di unione riuscita attiva la distribuzione della soluzione in un'area di lavoro di sviluppo usando una pipeline di Azure (non illustrata in questo diagramma). Quando si usa l'integrazione Git di Fabric, il ramo principale viene sincronizzato nell'area di lavoro di sviluppo.
	Il responsabile delle versioni esegue la revisione finale e l'approvazione della soluzione. Questa approvazione di versione impedisce la pubblicazione della soluzione prima che sia pronta. Nella pubblicazione di contenuti aziendali, un gestore delle versioni pianifica e coordina in genere la versione del contenuto in aree di lavoro di test e produzione. Coordina e comunica con creatori di contenuti, stakeholder e utenti.
	Quando il responsabile delle versioni approva la versione, Azure Pipelines prepara automaticamente la soluzione per la distribuzione. In alternativa, una pipeline di Azure può anche attivare una pipeline di distribuzione per promuovere il contenuto tra aree di lavoro.
	Gli utenti testano e convalidano il contenuto nell'area di lavoro di test. Quando si usa l'integrazione Git con Azure Pipelines per la distribuzione, l'area di lavoro di test non viene sincronizzata con alcun ramo.
	Dopo che gli utenti accettano e convalidano le modifiche, il responsabile della versione esegue una revisione finale e l'approvazione della soluzione da distribuire nell'area di lavoro di produzione.
	Gli utenti visualizzano il contenuto pubblicato nell'area di lavoro di produzione. Quando si usa l'integrazione Git con Azure Pipelines per la distribuzione, l'area di lavoro di produzione non viene sincronizzata con alcun ramo.

Le sezioni seguenti descrivono considerazioni aggiuntive per l’uso efficace del controllo del codice sorgente tramite Azure DevOps e Power BI.

Importante

L'uso efficace della ramificazione, dei commit, delle richieste pull e delle unioni è essenziale per sfruttare al meglio il controllo del codice sorgente quando si gestisce il ciclo di vita del contenuto di Power BI.

Utilizzare i rami

Gli autori di contenuti ottengono la collaborazione usando una strategia di diramazione. Una strategia di diramazione consente ai singoli creatori di contenuti di lavorare in isolamento nel repository locale. Quando sono pronti, combinano le modifiche come singola soluzione nel repository remoto. Gli autori di contenuti devono definire l'ambito del proprio lavoro in rami collegandoli agli elementi di lavoro per sviluppi, miglioramenti o correzioni di bug specifici. Ogni creatore di contenuti crea il proprio ramo del repository remoto per il proprio ambito di lavoro. Viene eseguito il commit del lavoro svolto sulla soluzione locale e viene eseguito il push in una versione del ramo nel repository remoto con un messaggio di commit descrittivo. Un messaggio di commit descrive le modifiche apportate in tale commit.

Quando si usa una strategia di diramazione per gestire il contenuto di Fabric, prendere in considerazione i fattori seguenti.

• Quale ramo devono clonare i creatori di contenuti per il proprio lavoro. Ad esempio, se questi rami sono un clone del ramo principale (noto come sviluppo basato su trunk) o se sono altri rami, come i rami di rilascio per versioni specifiche e pianificate del contenuto.
• Se si definisce l'ambito di operazioni specifiche per versioni di contenuto distinte usando i rami di rilascio.
• Quali rami si connettono all'area di lavoro quando si usa l'integrazione Git di Fabric.

Suggerimento

Vedere Adottare una strategia di diramazione Git per indicazioni e consigli specifici su come usare al meglio una strategia di diramazione per facilitare efficacemente la collaborazione.

Modifiche in batch nei commit

Durante lo sviluppo di contenuti, i creatori devono preparare regolarmente le modifiche in batch (o gruppi). Queste modifiche devono riguardare un elemento di lavoro specifico per la soluzione, ad esempio una funzionalità o un problema. Quando sono pronti, i creatori di contenuti eseguono il commit di queste modifiche a fasi.

La suddivisione delle modifiche in batch in questo modo offre diversi vantaggi.

• Aiuta a strutturare lo sviluppo e offre ai creatori di contenuti la possibilità di esaminare e documentare le modifiche raggruppate.
• Migliora l'allineamento tra pianificazione e sviluppo, rendendo più semplice collegare funzionalità e problemi e ottenere trasparenza sul modo in cui il lavoro sta procedendo.
• I proprietari tecnici possono esaminare più facilmente le richieste pull dei creatori di contenuti se le modifiche vengono raggruppate in modo appropriato e hanno messaggi di commit chiari.

Quando ci si prepara e si esegue il commit delle modifiche al contenuto di Power BI, prendere in considerazione i fattori seguenti.

• Il fatto che ci si prepari e si esegua o meno il commit delle modifiche da un repository locale o dall'area di lavoro Fabric.
• Posizionare i file con estensione pbip in cartelle di primo livello quando si archiviano più modelli o report in un unico repository. In questo modo sarà più semplice identificare e raggruppare le modifiche apportate.
• Ignorare modifiche innocue o inutili ai metadati usando un file gitignore o un file .gitattributes. In questo modo si garantisce che tutte le modifiche di cui si esegue il commit siano significative.

Suggerimento

Vedere Salvare il lavoro con i commit per indicazioni e consigli specifici su come preparare ed eseguire il commit del lavoro in un repository Git.

Creare richieste pull per unire le modifiche

Per unire le modifiche, un creatore di contenuti apre una richiesta pull. Una richiesta pull è un invio per la revisione paritaria che può portare all'unione del lavoro svolto in una singola soluzione. L'unione può comportare conflitti, che devono essere risolti prima che il ramo possa essere unito. Le revisioni delle richieste pull sono importanti per garantire che gli autori rispettino gli standard e le procedure organizzative per lo sviluppo, la qualità e la conformità.

Quando si usano le richieste pull per unire le modifiche al contenuto di Power BI, prendere in considerazione i fattori seguenti.

• Quali standard e procedure verranno usati per eseguire la revisione, se disponibile. Ad esempio, è possibile usare regole dell’analizzatore delle procedure consigliate per i modelli semantici.
• Come esaminare le modifiche apportate ai metadati del report, che non sono facili da leggere e comprendere senza l’uso di strumenti di terze parti.
• Come individuare e risolvere i conflitti di unione.

Suggerimento

Vedere Informazioni sulle richieste pull e Strategie di unione e merge con squash per indicazioni e consigli specifici su come usare al meglio le richieste pull per facilitare la collaborazione unendo le modifiche al contenuto.

Elenco di controllo: quando si pianificano le posizioni in cui verranno archiviati i file, le decisioni chiave e le azioni includono:

• Scegliere gli strumenti di sviluppo: assicurarsi che l'approccio allo sviluppo di contenuti sia allineato al modo in cui si collaborerà con altri creatori di contenuti e si userà il controllo della versione.
• Scegliere tra formati .pbip e .pbix per modelli e report: in genere, il formato con estensione pbip è più vantaggioso per il controllo del codice sorgente, ma gli utenti self-service possono trovare i file con estensione pbix più facili da usare.
• Modello semantico e sviluppo di report separato: il controllo della versione è più efficace quando si gestiscono le modifiche per tipi di elementi diversi, separatamente. La separazione del modello e dello sviluppo di report è considerata una procedura consigliata.
• Decidere quante aree di lavoro sono necessarie: l'uso di ambienti separati è fondamentale per il successo della gestione del ciclo di vita dei contenuti. Assicurarsi di aver specificato il numero di aree di lavoro necessarie e di eseguire una pianificazione appropriata a livello di area di lavoro.
• Decidere come implementare il controllo della versione: decidere tra un approccio più semplice con SharePoint o OneDrive for Business o con Azure DevOps per facilitare il controllo del codice sorgente.
• Configurare il repository remoto: creare uno spazio strutturato nella cartella OneDrive o nel repository Git in cui archiviare il contenuto per tenere traccia e gestire le modifiche.
• Se si usa il controllo del codice sorgente, configurare i file con estensione gitignore e gitattributes: assicurarsi di configurare il repository in modo da tenere traccia delle sole modifiche significative.
• Se si usa il controllo del codice sorgente, definire strategie di diramazione e unione: assicurarsi di definire processi chiari per la configurazione e l'uso del controllo del codice sorgente per supportare al meglio lo sviluppo. Evitare di complicare ulteriormente il processo. Provare invece a integrare il modo di lavorare attuale nei team di sviluppo.

Contenuto correlato

Nell'articolo successivo di questa serie viene illustrato come convalidare il contenuto come parte della gestione del ciclo di vita del contenuto.