Pianificazione dell'implementazione di Power BI: Sviluppare contenuto 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 di Power BI all'interno di Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

Questo articolo consente di sviluppare contenuto e gestire le modifiche come parte della gestione del ciclo di vita del contenuto. È destinato principalmente a:

• Centro di eccellenza (COE) e team bi: i 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 i responsabili delle versioni, che gestiscono il ciclo di vita delle versioni del contenuto o i 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 contenuto, che vogliono pubblicare 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 è i processi e le 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 distribuzione stabile e coerente dei contenuti ai consumer.

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 contenuto e gestire le modifiche durante il ciclo di vita. Per altre indicazioni su come sviluppare contenuto 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 contenuto e gestire le modifiche.
• Integrazione di OneDrive e SharePoint di Power BI Desktop: questo articolo contiene una panoramica delle opzioni per usare e archiviare i file salvati in OneDrive for Work e School o SharePoint quando si esegue il controllo della versione con file con estensione 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.

Gli autori di contenuti e i proprietari devono gestire le modifiche del contenuto 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 la collaborazione e la gestione dei contenuti più efficaci.

Altri vantaggi del controllo della versione includono la possibilità di:

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

Suggerimento

È consigliabile usare il controllo della versione per tutto il contenuto creato, se possibile. L'uso del controllo della versione offre vantaggi significativi sia per gli autori di contenuti che per i consumer 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 contenuto.

Decidere come sviluppare contenuto

A seconda del modo in cui crei contenuto, dovrai prendere decisioni diverse su come gestirlo. Ad esempio, per i report di Power BI e i modelli semantici, un file di Power BI Desktop (con estensione pbix) include meno opzioni per il controllo della versione rispetto al formato del progetto power BI Desktop (con estensione pbip). Questo perché un file con estensione pbix è un formato binario, mentre il formato pbip contiene contenuto leggibile e metadati basati sul testo. La presenza di contenuto e metadati leggibili consente di tenere traccia più facilmente delle modifiche del modello e del report usando il controllo del codice sorgente. Il controllo del codice sorgente è 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é file con estensione 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 con estensione pbip e TMDL supportano il rilevamento e l'unione semplificate 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 con estensione pbix o pbip. Quando si usa Power BI Desktop. Quando si usa Power BI Desktop per creare contenuto, è anche possibile usare altri file di contenuto personalizzati, alcune decisioni chiave da prendere includono:

• Formato di file da usare: è possibile salvare il contenuto come file con estensione pbix o pbip. Ad esempio, l'integrazione git richiede l'uso di file con estensione pbip, gli autori self-service potrebbero trovare file con estensione pbix più semplici da gestire e gestire in Teams, SharePoint o OneDrive.
• Come gestire il contenuto personalizzato: è 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 gli autori di contenuti creano oggetti visivi personalizzati, devono salvare e gestire la definizione visiva in un file separato.
• Come gestire le funzionalità di anteprima: è possibile acconsentire esplicitamente alle funzionalità o alle impostazioni di anteprima in Power BI Desktop, che modifica il contenuto e come 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. È anche 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, è possibile evitare la creazione Web su elementi condivisi, invece di lavorare 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 flusso di dati e il recupero 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 traccia delle modifiche o recuperare facilmente 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 pivot che funzionano con un modello semantico.
• Power BI Generatore report: un'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à di Infrastruttura. In questo modo si evita che le risorse usate per lo sviluppo e il test interrompano i carichi di lavoro di produzione, causando aggiornamenti o report dei dati lenti.
• È possibile creare un processo più strutturato per sviluppare, testare e rilasciare contenuto con ambienti discreti per ognuna di queste fasi. Ciò consente di migliorare la produttività.

In Infrastruttura e Power BI è consigliabile usare aree di lavoro di Infrastruttura 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 usando 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 di 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 per 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 da 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 codice tramite le API REST di Infrastruttura, 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, gli autori 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 solo un'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
	Gli autori di contenuti sviluppano contenuti nell'ambiente locale.
	Quando sono pronti, gli autori di contenuti pubblicano il contenuto in un'area di lavoro di test. Gli autori 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, gli autori di contenuti distribuiscono il contenuto in un'area di lavoro di produzione. Nell'area di lavoro di produzione gli autori 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 business critical, in genere si usano tre o più aree di lavoro separate. In questo scenario, gli autori 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
	Gli autori di contenuti sviluppano contenuti nell'ambiente locale.
	Quando sono pronti, gli autori di contenuti pubblicano il contenuto in un'area di lavoro di sviluppo. Nell'area di lavoro sviluppo gli autori di contenuti possono sviluppare contenuti che possono essere prodotti solo con la creazione Web. Gli autori di contenuti possono anche convalidare il contenuto nell'area di lavoro di sviluppo.
	Quando sono pronti, gli autori di contenuti distribuiscono il contenuto in un'area di lavoro di test. Nell'area di lavoro di test gli utenti convalidano il contenuto nell'area di lavoro o in un'app.
	Quando sono pronti, gli autori di contenuti distribuiscono il contenuto in un'area di lavoro di produzione. Nell'area di lavoro di produzione gli autori 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 business critical, ogni sviluppatore può anche usare la propria area di lavoro privata per lo sviluppo. In questo scenario, un'area di lavoro privata consente agli autori 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. Gli autori di contenuti possono anche sviluppare contenuto 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 un percorso di archiviazione remoto usato 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.
• Piani di test di Azure: consente di progettare test per convalidare la soluzione e automatizzare il controllo della 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 Di 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 con Git.

Nota

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

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

Articolo	Descrizione
	Ogni autore di contenuti sviluppa contenuto nel proprio ambiente locale.
	Quando sono pronti, gli autori 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 gli autori di contenuti tengono traccia e gestiscono le modifiche del contenuto usando il controllo del codice sorgente e diramano e uniscono il contenuto per facilitare la collaborazione.
	Gli autori 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, separati rami man mano che apportano modifiche.
	Nelle aree di lavoro private gli autori di contenuti possono sviluppare contenuti usando la creazione Web e convalidare le proprie modifiche. Le modifiche apportate al contenuto apportato dalla creazione Web possono essere sincronizzate con il ramo nel repository Git quando l'autore del contenuto esegue il commit ed esegue 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, gli autori 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 gli autori di contenuti possono sviluppare contenuto non supportato dall'integrazione Git di Fabric, ad esempio i dashboard. Gli autori di contenuti convalidano anche la soluzione integrata che contiene tutte le modifiche più recenti.
	Quando sono pronti, gli autori 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, gli autori di contenuti distribuiscono il contenuto in un'area di lavoro di produzione. Nell'area di lavoro di produzione gli autori 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 e 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 usando 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 un percorso 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à 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 quando altri utenti aggiungono, rimuovono o modificano i 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 al percorso di archiviazione remota per descrivere il percorso di archiviazione remota e i relativi scopi, proprietà, accesso e processi definiti.

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

Controllo della versione tramite SharePoint o OneDrive for Work e School

SharePoint dispone del controllo della versione predefinito per i file. Gli autori di contenuti possono sviluppare modelli semantici o report in locale e le relative modifiche vengono sincronizzate con una raccolta documenti di SharePoint o OneDrive for Work and School.

Suggerimento

Usare SharePoint o OneDrive solo per il controllo della versione in scenari più semplici e più piccoli, ad esempio 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
	Gli autori di contenuti sviluppano modelli semantici e report nell'ambiente locale e salvano questi modelli e report come file con estensione pbix.
	Quando sono pronti, gli autori di contenuti salvano le modifiche, che sincronizzano con una raccolta remota di SharePoint o OneDrive for Work and School.
	Nella raccolta remota i creatori di contenuti tengono traccia delle modifiche a livello di file che facilitano il controllo della versione.
	Gli autori 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 Infrastruttura gli autori 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, ad esempio flussi di dati o per tipi di elementi di Infrastruttura come notebook. Per questi altri tipi di elementi, è consigliabile eseguire il controllo della versione usando un repository Git remoto, ad esempio Azure Repos.

Per riepilogare, gli autori 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 for Work and School. Con questo approccio, gli autori 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 si verifica ogni ora. Anche se pratico, questo approccio include alcune considerazioni e non può essere facilmente invertito.

Sebbene sia facile da configurare e 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 è anche possibile confrontare le versioni. Inoltre, non è possibile configurare processi più sofisticati per gestire queste modifiche,ad esempio le richieste di diramazione 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 con estensione pbix.
• Gli utenti self-service creano e gestiscono il contenuto.
• Gli autori di contenuti collaborano usando Microsoft Teams.
• I creatori di contenuti sono inesperti con git e la gestione del controllo del codice sorgente.
• Gli autori di contenuti gestiscono un singolo elemento con complessità e collaborazione limitate.
• I file con estensione pbix hanno un'etichetta di riservatezza applicata che ne crittografa il contenuto.

Nota

OneDrive e SharePoint supportano il contenuto con etichette di riservatezza applicate, ad eccezione di alcuni scenari limitati. Al contrario, l'integrazione git di 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.
• Gli autori 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 gli autori di contenuti lo usano per la collaborazione. Le raccolte documenti sono siti di SharePoint e usano le raccolte documenti (anziché un sito di SharePoint separato o una cartella di OneDrive) garantisce la centralizzazione di contenuto, file e collaborazione.

Archiviare e archiviare i file

È consigliabile archiviare i file su cui si sta lavorando per evitare possibili conflitti di modifica. Al termine delle modifiche, archiviare i file con commenti che descrivono la modifica. L'archiviazione e l'estrazione dei file consente di migliorare la collaborazione tra creatori di contenuti quando si usa SharePoint o OneDrive for Work e School per il controllo della versione. Se si archivia e si estraeno file con più autori di contenuti, è possibile modificare la raccolta siti di SharePoint per visualizzare l'ultimo aggiornamento e i commenti dell'ultima archiviazione.

Cronologia delle versioni

Assicurarsi di eseguire il backup del contenuto in un percorso separato in caso di interruzioni impreviste nella raccolta documenti del sito di SharePoint. È inoltre consigliabile impostare 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 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, che consente ai creatori di contenuti di più opzioni di tenere traccia e gestire le modifiche. In breve, gli autori 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

È anche 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
	Gli autori di contenuti sviluppano modelli semantici e report nell'ambiente locale e salvano questi modelli e report come file con estensione pbip. Gli autori di contenuti possono anche sviluppare modelli semantici e salvare i metadati del modello.
	Quando sono pronti, gli autori di contenuti salvano le modifiche, che 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, che facilitano il controllo della versione. Gli autori di contenuti possono anche creare rami per lavorare sul contenuto e unire le modifiche in un singolo ramo usando le richieste pull.
	Gli autori 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 Infrastruttura gli autori di contenuti visualizzano le modifiche apportate al contenuto di Power BI al termine della sincronizzazione o della distribuzione. Gli autori di contenuti possono creare contenuti come flussi di dati o notebook nell'area di lavoro. Se usano l'integrazione Git, gli autori di contenuti collegano questa area di lavoro a un ramo specifico del repository remoto.
	Gli autori 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 e dell'unione in un'unica soluzione. Azure Repos offre opzioni più sofisticate per tenere traccia e gestire le modifiche rispetto a SharePoint e OneDrive. La gestione di un repository ben curato e documentato è essenziale perché è la base di tutto il contenuto e la 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.
• Gli autori di contenuti collaborano usando Azure DevOps.
• Gli autori di contenuti hanno familiarità con Git, la gestione del controllo del codice sorgente o i principi DataOps.
• Gli autori di contenuti gestiscono contenuti complessi o importanti o prevedono che il contenuto venga ridimensionato e cresciuto in 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, gli autori 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, gli autori 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 Di Azure Repos, gli autori di contenuti devono avere quanto segue:
  • Livello di accesso impostato su Basic (anziché stakeholder).
  • Appartenere a un'organizzazione e a un progetto.
  • Autorizzazioni appropriate per il repository.
• Integrazione git dell'infrastruttura: per sincronizzare il contenuto in un repository remoto con un'area di lavoro di Microsoft Fabric, gli autori di contenuti usano l'integrazione git di 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 il staging, il commit e il push delle modifiche nel repository remoto.

Avviso

L'integrazione git di 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 di 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 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 con il 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, i processi e le funzionalità utente 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 merge 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 con l'area di lavoro di sviluppo.
	Il responsabile delle versioni esegue una 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 responsabile delle versioni pianifica e coordina in genere il rilascio del contenuto per testare e creare aree di lavoro di produzione. Coordinano e comunicano 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 usare in modo efficace il controllo del codice sorgente usando Azure DevOps e Power BI.

Importante

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

Usare 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. Il lavoro svolto nella soluzione locale viene eseguito il commit e 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.

• Quali creatori di contenuti di rami devono clonare 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.
• Indica se definire 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 risolvere un elemento di lavoro specifico per la soluzione, ad esempio una funzionalità o un problema. Quando sono pronti, gli autori di contenuti eseguono il commit di queste modifiche a fasi.

L'invio in batch delle modifiche in questo modo offre diversi vantaggi.

• Aiuta a strutturare lo sviluppo e offre agli autori 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 si esegue la fase e si esegue il commit delle modifiche al contenuto di Power BI, prendere in considerazione i fattori seguenti.

• Se si eseguirà il commit delle modifiche da un repository locale o dall'area di lavoro Infrastruttura.
• 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 con estensione 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 peer 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 di Best Practice Analyzer per i modelli semantici.
• Come esaminare le modifiche apportate ai metadati del report, che non è facile da leggere e comprendere senza usare strumenti di terze parti.
• Come risolvere e risolvere i conflitti di unione.

Suggerimento

Vedere About pull requests and Merge strategies and squash merge (Informazioni sulle richieste pull e sulle strategie di merge) 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 : durante la pianificazione 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 con estensione 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 file con estensione pbix più facili da usare.
• Modello semantico separato e sviluppo di report: 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 usando SharePoint o OneDrive for Business o usando 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 solo delle 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 sovraplicare il processo. Provare invece a integrare il modo attuale di lavorare 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.