Pianificazione dell'implementazione di Power BI: distribuire il contenuto

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 consente di sviluppare il contenuto come parte della gestione del ciclo di vita del contenuto. È destinato principalmente a:

• Amministratori Fabric: amministratori responsabili della supervisione Fabric nell'organizzazione. Gli amministratori Fabric potrebbero dover collaborare con altri amministratori, ad esempio quelli che supervisionano Microsoft 365 o Azure DevOps.
• 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 responsabili delle versioni, che gestiscono il ciclo di vita delle versioni del contenuto e 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 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 è costituita dai processi e dalle procedure usate per gestire il contenuto dalla creazione al ritiro finale. Nella terza fase della gestione del ciclo di vita si convalidano le modifiche al contenuto, che comportano la convalida eseguita sia dai creatori di contenuti che dagli utenti. Nella quarta fase si distribuisce il contenuto per l’uso da parte dei fruitori.

Per condividere il contenuto di Power BI con i fruitori, è necessario pubblicare (o distribuire) il contenuto in un'area di lavoro Fabric. La distribuzione del contenuto comporta anche lo spostamento del contenuto tra ambienti, ad esempio la distribuzione da un'area di lavoro di sviluppo a un'area di lavoro di test o da un'area di lavoro di test a un'area di lavoro di produzione.

L'immagine seguente illustra il ciclo di vita del contenuto di Power BI, evidenziando la fase quattro, in cui si distribuisce il contenuto.

Nota

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

Questo articolo è incentrato sulle considerazioni e sulle decisioni principali per la distribuzione del contenuto durante il ciclo di vita. Per altre indicazioni su come distribuire il contenuto, vedere:

• Eseguire la migrazione a Power BI: distribuire il contenuto: questo articolo descrive le considerazioni e le decisioni principali per la distribuzione quando si esegue la migrazione a Power BI da altre tecnologie.
• Pianificazione della soluzione BI: distribuire, supportare e monitorare: questo articolo descrive come pianificare la distribuzione quando si crea per la prima volta la soluzione Power BI o Fabric.
• Pianificazione dell'implementazione di Power BI: scenario di utilizzo della pubblicazione di contenuti self-service: questo articolo descrive il modo in cui gli utenti self-service possono distribuire il contenuto usando le pipeline di distribuzione di OneDrive per le aziende e gli istituti di istruzione e Fabric.
• Pianificazione dell'implementazione di Power BI: scenario di utilizzo della pubblicazione di contenuti aziendali: questo articolo descrive il modo in cui i team centrali possono distribuire e gestire il contenuto usando Azure DevOps.

Il contenuto viene distribuito in due punti principali durante il ciclo di vita del contenuto:

• Quando si pubblica il contenuto in un'area di lavoro di sviluppo. A questo punto, si pubblica il contenuto per convalidare le modifiche.
• Quando si alza di livello il contenuto tra due aree di lavoro, ad esempio quando si alza di livello il contenuto da un'area di lavoro di sviluppo a un'area di lavoro di test. A questo punto, si distribuisce il contenuto quando è pronto per la fase successiva, ad esempio quando il nuovo contenuto è pronto per essere testato.

Le sezioni seguenti illustrano gli approcci che è possibile adottare per pubblicare o alzare di livello il contenuto.

Decidere come pubblicare il contenuto

Quando si sviluppa contenuto nel computer locale, è necessario pubblicare il contenuto in un'area di lavoro di sviluppo nel portale di Fabric. Questo contenuto viene in genere pubblicato quando si desidera eseguire la convalida delle modifiche apportate.

Nota

In questo articolo si intende per pubblicazione di contenuto la distribuzione iniziale nell'area di lavoro di sviluppo. Tuttavia, in linea di principio, la pubblicazione del contenuto equivale alla distribuzione.

Il contenuto creato nel portale di Fabric (ad esempio flussi di dati, dashboard e scorecard) viene creato direttamente nell'area di lavoro di sviluppo e non deve essere pubblicato.

Le sezioni seguenti descrivono diversi approcci che è possibile adottare per pubblicare contenuto.

Pubblicare con Power BI Desktop

Power BI Desktop consente agli utenti di pubblicare modelli semantici e report del computer locale in un'area di lavoro nel portale di Fabric. Questo approccio è il modo più semplice per pubblicare il contenuto; tuttavia, non può essere automatizzato.

Prendere in considerazione l'uso di questo approccio quando:

• I creatori di contenuti preferiscono controllare manualmente la pubblicazione del contenuto nel portale di Fabric.
• I creatori di contenuti usano Power BI Desktop per sviluppare e gestire il contenuto.
• I creatori di contenuti non hanno familiarità con Azure DevOps o Git.
• Il contenuto include solo modelli semantici o report.

Pubblicare con strumenti di terze parti

Gli strumenti di terze parti consentono ai creatori di contenuti di pubblicare un modello semantico usando l'endpoint di lettura/scrittura XMLA dell'area di lavoro. Ad esempio, un creatore di contenuti usa l'editor tabulare per sviluppare e gestire i metadati del modello, come i file TMDL (Tabular Model Definition Language) o bim.

Suggerimento

Per altre informazioni su come usare strumenti di terze parti per distribuire modelli semantici, vedere lo scenario di utilizzo di gestione avanzata dei modelli di dati.

Per altre informazioni su come abilitare e usare endpoint di lettura/scrittura XMLA, vedere Connettività del modello semantico con l'endpoint XMLA.

Prendere in considerazione l'uso di questo approccio quando:

• I creatori di contenuti preferiscono controllare manualmente la pubblicazione del contenuto nel portale di Fabric.
• I creatori di contenuti usano uno strumento di terze parti per sviluppare e gestire il contenuto.
• Il contenuto verrà pubblicato in un'area di lavoro che usa Premium per utente (PPU), capacità Premium o modalità di licenza della capacità Fabric.
• I creatori di contenuti non hanno familiarità con Azure DevOps o Git.
• Il contenuto comprende solo modelli semantici.

Pubblicare con l'aggiornamento di OneDrive

OneDrive consente ai creatori di contenuti self-service di pubblicare automaticamente modelli semantici o report in un'area di lavoro del portale di Fabric usando l'aggiornamento di OneDrive. I creatori di contenuti possono salvare i file di Power BI Desktop (.pbix) in una raccolta condivisa in OneDrive. La raccolta condivisa può anche essere una raccolta documenti di SharePoint o Microsoft Teams.

Suggerimento

Per altre informazioni su come usare OneDrive per le aziende e gli istituti di istruzione con il contenuto di Power BI, vedere lo scenario di utilizzo della pubblicazione di contenuti self-service.

Per altre informazioni su come configurare l'aggiornamento di OneDrive, vedere Aggiornare un modello semantico archiviato in OneDrive o SharePoint Online.

Prendere in considerazione l'uso di questo approccio quando:

• I creatori di contenuti vogliono automatizzare la pubblicazione del contenuto nel portale di Fabric.
• I creatori di contenuti non hanno familiarità con Azure DevOps o Git.
• I creatori di contenuti eseguono il controllo della versione del contenuto usando OneDrive o SharePoint.
• I creatori di contenuti salvano i modelli semantici e i report come file .pbix.
• Il contenuto include solo modelli semantici o report.

Pubblicare con l'integrazione Git di Fabric

L'integrazione Git di Fabric è una funzionalità esclusiva delle capacità Fabric che consente ai creatori di contenuti di sincronizzare un ramo di un repository Git remoto con un'area di lavoro di Fabric. È possibile usare l'integrazione Git insieme ad Azure DevOps per sincronizzare il contenuto da Azure Repos oppure distribuire il contenuto usando Azure Pipelines (descritto nella sezione successiva).

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.

Per riepilogare, il contenuto di cui è stato eseguito il commit e il push nel repository remoto viene pubblicato automaticamente nell'area di lavoro tramite questo processo di sincronizzazione. Un vantaggio fondamentale di questo approccio è che consente di associare i processi di gestione del controllo del codice sorgente alla pubblicazione del contenuto. Ad esempio, consente di eseguire più facilmente il rollback delle modifiche o di intere versioni di una soluzione.

Suggerimento

Per altre informazioni su come usare l'integrazione Git di Fabric per distribuire il contenuto di Power BI, vedere lo scenario di utilizzo della pubblicazione di contenuti aziendali.

Per altre informazioni su come configurare l'integrazione Git, vedere Esercitazione: Gestione del ciclo di vita in Fabric e Progetti Power BI Desktop: integrazione Git.

Prendere in considerazione l'uso di questo approccio quando:

• I creatori di contenuti hanno familiarità con Azure DevOps e Git.
• I creatori di contenuti usano Azure DevOps per la collaborazione e il controllo del codice sorgente.
• I creatori di contenuti salvano i modelli semantici e i report come file di progetto Power BI (.pbip).
• Il contenuto verrà pubblicato in un'area di lavoro su una capacità Fabric.
• Il contenuto è costituito dai tipi di elementi supportati dalla funzionalità di integrazione Git.
• Il contenuto non ha etichette di riservatezza.

Nota

Il modo in cui si usa l'integrazione Git per distribuire e gestire il contenuto dipende in larga misura dalle strategie di diramazione e unione, che si decidono nella fase due della gestione del ciclo di vita.

Pubblicare con Azure Pipelines

Azure Pipelines automatizza a livello di codice i test, la gestione e la distribuzione del contenuto. Quando viene eseguita una pipeline, i passaggi nella pipeline vengono eseguiti automaticamente. Azure Pipelines è più complesso e richiede più tempo e impegno per la configurazione rispetto ad altri approcci, ma consente massimo controllo e flessibilità per orchestrare il processo di distribuzione.

Suggerimento

È possibile distribuire il contenuto usando Azure Pipelines e le API REST di Power BI nelle aree di lavoro che non si trovano nella capacità Fabric o Premium. Tuttavia, le API REST di Fabric funzionano solo con Fabric e gli endpoint XMLA funzionano solo con la capacità Fabric o Premium.

Per altre informazioni su come usare Azure Pipelines per distribuire il contenuto di Power BI, vedere lo scenario di utilizzo della pubblicazione di contenuti aziendali.

Per altre informazioni su come integrare Azure DevOps con Power BI, vedere Integrazione Azure DevOps dei progetti di Power BI Desktop e pipeline di compilazione.

Prendere in considerazione l'uso di Azure Pipelines per orchestrare la distribuzione del contenuto quando:

• I creatori di contenuti hanno familiarità con Azure DevOps e le API REST di Fabric.
• I creatori di contenuti usano Azure DevOps per la collaborazione e il controllo del codice sorgente.
• I creatori di contenuti non usano l'integrazione Git di Fabric.

Azure Pipelines e altri strumenti basati su codice possono distribuire contenuto a livello di programmazione usando una o più delle seguenti API o endpoint:

• API REST di Power BI: ci sono diversi endpoint dell'API REST di Power BI utilizzabili per distribuire il contenuto. Le API REST di Power BI supportano solo i tipi di elementi di Power BI.
  • Importare: è possibile pubblicare elementi supportati usando le API REST di Power BI per importare un file di origine valido in un'area di lavoro, ad esempio un file con estensione pbix.
  • Distribuire: è possibile distribuire gli elementi supportati, promuovendoli da un'area di lavoro a un'altra se sono fasi di una pipeline di distribuzione.
• API REST di Fabric: ci sono diversi endpoint dell'API REST di Fabric utilizzabili per distribuire il contenuto. Le API REST di Fabric supportano sia i tipi di elementi di Power BI che di Fabric.
  • Creare: è possibile creare elementi supportati usando le API REST di Fabric insieme a una definizione di elemento valida.
  • Aggiornare da Git: è possibile aggiornare un'area di lavoro con contenuto di un repository remoto connesso usando l'integrazione Git.
• Endpoint di lettura/scrittura XMLA: è possibile creare o modificare modelli semantici usando endpoint XMLA insieme a un file model.bim valido. Gli endpoint XMLA consentono di distribuire modifiche a oggetti modello specifici anziché all'intero modello. Azure Pipelines può usare strumenti di terze parti (ad esempio l'interfaccia della riga di comando dell'editor tabulare) per distribuire modelli semantici usando gli endpoint XMLA.

Suggerimento

Quando si usano le API REST di Fabric o Power BI, è prima necessario creare una registrazione dell'app in Azure (descritta qui per Power BI Embedded). Questo richiede un tenant di Microsoft Entra ID e un utente aziendale e può essere un processo complesso per configurare le autorizzazioni appropriate. Tuttavia, è possibile eseguire le API REST Fabric nei notebook senza creare una registrazione dell'app. Ciò semplifica la configurazione e l'uso delle API nelle soluzioni, in modo che non sia necessario gestire le credenziali né configurare alcun setup prima di usare le API.

Per usare le API REST di Fabric senza registrare un'app, usare il collegamento semantico in un notebook di Fabric con FabricRestClientClass di sempy per chiamare l'API.

Insieme ai test automatizzati, l'integrazione di Azure Pipelines con Power BI consente di ottenere l'integrazione continua e la distribuzione continua (CI/CD).

Quando si usa Azure Pipelines, i proprietari della pipeline possono personalizzare trigger, passaggi e funzionalità per soddisfare le esigenze di distribuzione. Di conseguenza, il numero e i tipi di pipeline variano a seconda dei requisiti della soluzione.

Esistono tre tipi di Azure Pipelines che è possibile configurare per testare, gestire e distribuire la soluzione Power BI.

• Pipeline di convalida
• Pipeline di compilazione
• Pipeline di versione

Nota

Non è necessario avere tutti e tre i tipi di pipeline nella soluzione di pubblicazione. A seconda del flusso di lavoro e delle esigenze, è possibile configurare una o più varianti delle pipeline descritte in questo articolo per automatizzare la pubblicazione del contenuto. Questa possibilità di personalizzare le pipeline è un vantaggio di Azure Pipelines rispetto alle pipeline di distribuzione di Fabric predefinite.

Pipeline di convalida

Le pipeline di convalida eseguono controlli qualitativi di base dei modelli di dati prima che questi vengano pubblicati in un'area di lavoro di sviluppo. In genere, le modifiche in un ramo del repository remoto attivano la pipeline per la convalida di tali modifiche con test automatizzati.

Esempi di test automatizzati includono l'analisi del modello di dati per individuare le violazioni delle regole consigliate usando Best Practice Analyzer (BPA) o eseguendo query DAX su un modello semantico pubblicato. I risultati di questi test vengono quindi archiviati nel repository remoto a scopo di documentazione e controllo. I modelli di dati che non superano la convalida non devono essere pubblicati. Al contrario, la pipeline deve notificare ai creatori di contenuti i problemi.

Pipeline di compilazione

Le pipeline di compilazione preparano i modelli di dati per la pubblicazione nel servizio Power BI. Queste pipeline combinano i metadati del modello serializzati in un singolo file pubblicato successivamente da una pipeline di versione. Una pipeline di compilazione può anche apportare modifiche ai metadati, ad esempio la modifica dei valori dei parametri. Le pipeline di compilazione producono artefatti di distribuzione costituiti da metadati del modello di dati (per i modelli di dati) e file di progetto Power BI (con estensione pbix) pronti per la pubblicazione nel servizio Power BI.

Pipeline di versione

Le pipeline di versione pubblicano o distribuiscono il contenuto. Una soluzione di pubblicazione include in genere diverse pipeline di versione, a seconda dell'ambiente di destinazione.

• Pipeline di versione di sviluppo: questa prima pipeline viene attivata automaticamente. Pubblica il contenuto in un'area di lavoro di sviluppo dopo che le pipeline di compilazione e convalida hanno esito positivo.
• Pipeline di versione di test e produzione: queste pipeline non vengono attivate automaticamente. Vengono invece attivate su richiesta o quando approvate. Le pipeline di versione di test e produzione distribuiscono il contenuto in un'area di lavoro di test o produzione, rispettivamente, dopo l'approvazione della versione. Le approvazioni delle versioni assicurano che il contenuto non venga distribuito automaticamente in una fase di test o produzione prima che sia pronto. Queste approvazioni vengono fornite dai gestori delle versioni, che sono responsabili della pianificazione e del coordinamento del rilascio dei contenuti in ambienti di test e produzione.

Decidere come promuovere il contenuto tra aree di lavoro

Quando si usano ambienti diversi per lo sviluppo, il test e la produzione, è necessario distribuire il contenuto in tutti e tre gli ambienti. Esistono diversi strumenti e approcci che è possibile adottare per promuovere il contenuto tra aree di lavoro, a seconda del flusso di lavoro e delle esigenze specifiche.

Le sezioni seguenti descrivono gli approcci che è possibile adottare per promuovere il contenuto tra aree di lavoro.

Attenzione

Evitare di pubblicare manualmente il contenuto dal computer locale per testare e creare aree di lavoro di produzione. Questo può causare errori o interruzioni a causa di imprecisioni. In genere, è consigliabile pubblicare in un'area di lavoro di sviluppo o in un'area di lavoro privata solo se ne viene usata una.

Eseguire la distribuzione con le pipeline di distribuzione di Fabric

Le pipeline di distribuzione consentono di configurare due o più fasi (ad esempio sviluppo, test o produzione) e distribuire il contenuto di Fabric tra queste fasi. Un amministratore della pipeline assegna una singola area di lavoro di Power BI a ogni fase della pipeline di distribuzione. Il modo in cui si usano le pipeline di distribuzione dipende da come si è deciso di configurare e usare le aree di lavoro.

È consigliabile usare le pipeline di distribuzione quando:

• Il contenuto viene distribuito nelle aree di lavoro con PPU, capacità Premium o modalità di licenza della capacità Fabric.
• I tipi di elementi di contenuto e gli scenari sono supportati dalle pipeline di distribuzione.

Valutare un altro approccio rispetto alle pipeline di distribuzione quando:

• Si preferisce distribuire contenuto da un repository remoto, ad esempio usando Azure Pipelines.
• Si intende usare l'integrazione Git per sincronizzare diverse fasi con rami diversi del repository remoto, anziché distribuire il contenuto.

Suggerimento

Per altre informazioni su come usare le pipeline di distribuzione per promuovere il contenuto tra aree di lavoro, vedere gli scenari di utilizzo della pubblicazione di contenuti self-service e della pubblicazione di contenuti aziendali.

Per altre informazioni sulle pipeline di distribuzione, vedere Pipeline di distribuzione: Informazioni sul processo di distribuzione.

Il modo più semplice per usare una pipeline di distribuzione consiste nel pubblicare tutto il contenuto in una singola area di lavoro e alzarlo di livello in fasi successive all'interno di una singola pipeline di distribuzione. Il diagramma seguente illustra questo primo approccio per distribuire il contenuto usando una pipeline di distribuzione.

In sintesi, un creatore di contenuti pubblica in genere il contenuto nella fase iniziale della pipeline. Quindi, per alzare di livello il contenuto alle fasi successive, un amministratore della pipeline attiva una distribuzione. Quando si verifica una distribuzione, la pipeline di distribuzione distribuisce i metadati del contenuto da un'area di lavoro alla successiva.

Quando si separa il contenuto in base al tipo di elemento in aree di lavoro diverse, si useranno pipeline di distribuzione separate per distribuire questo contenuto. È possibile collegare il contenuto tra aree di lavoro con più pipeline di distribuzione usando l'associazione automatica. L'associazione automatica tra le pipeline di distribuzione garantisce che il contenuto rimanga collegato all'elemento appropriato nella rispettiva fase. Ad esempio, il report nella fase di sviluppo rimarrà collegato al modello nella fase di sviluppo dell'altra pipeline di distribuzione. Tuttavia, è possibile evitare il comportamento di associazione automatica se lo scenario richiede di collegare il contenuto tra aree di lavoro con un modello diverso.

Il diagramma seguente illustra questo secondo approccio per distribuire il contenuto usando più pipeline di distribuzione.

In sintesi, la distribuzione del contenuto usando più pipeline di distribuzione è simile all'uso di una singola pipeline. Una differenza fondamentale sta nel fatto che è possibile collegare facoltativamente il contenuto connesso tra aree di lavoro e pipeline di distribuzione usando l'associazione automatica. Per il resto, è identico al primo approccio.

Le pipeline di distribuzione sono uno strumento semplice e flessibile, adatto per migliorare la gestione del ciclo di vita del contenuto sia per scenari self-service che aziendali.

L'accesso all'area di lavoro e alla pipeline di distribuzione è necessario per gli utenti che eseguono una distribuzione. È consigliabile pianificare l'accesso alla pipeline di distribuzione in modo che gli amministratori della pipeline possano visualizzare la cronologia di distribuzione e confrontare il contenuto. Quando si collabora con più creatori di contenuti, è consigliabile limitare l'accesso alla pipeline ai responsabili delle versioni o ai proprietari tecnici più adatti per supervisionare i processi di distribuzione e rilascio.

È inoltre consigliabile usare regole di distribuzione per impostare configurazioni diverse per gli elementi in fasi diverse. Ad esempio, potrebbe essere necessario un modello semantico nell'area di lavoro di sviluppo per l'origine dei dati del database di sviluppo, mentre il modello semantico nell’area di lavoro di produzione raccoglie i dati dal database di produzione.

Suggerimento

Se più persone hanno accesso alla pipeline di distribuzione, è consigliabile esaminare regolarmente la cronologia di distribuzione. Queste revisioni consentono di identificare le distribuzioni non approvate o gli errori di distribuzione.

Se si usa l’associazione automatica per collegare elementi tra le pipeline di distribuzione, assicurarsi di esaminare anche le derivazioni degli elementi per identificare le interruzioni nell'associazione automatica causate da un utente che pubblica contenuto collegato alla fase sbagliata.

È possibile attivare le distribuzioni manualmente o a livello di programmazione usando le API REST di Power BI. In entrambi i casi, è necessario definire un processo chiaro e affidabile su quando si alza di livello il contenuto a ogni fase e su come eseguire il rollback delle modifiche impreviste.

Eseguire manualmente la distribuzione

È possibile distribuire il contenuto manualmente usando la pipeline di distribuzione di Fabric. È possibile scegliere di distribuire tutto il contenuto o selezionare gli elementi. La distribuzione selettiva può essere utile quando alcuni contenuti sono pronti per passare alla fase successiva, ma alcuni elementi sono ancora in fase di sviluppo o convalida. Inoltre, è possibile eseguire una distribuzione a ritroso quando le modifiche al contenuto esistono in una fase successiva, ma non in una precedente.

Attenzione

Quando si usano le pipeline di distribuzione, è consigliabile distribuire il contenuto in un'unica direzione, ad esempio dalle aree di lavoro di sviluppo, a quelle di test e produzione. In genere, è consigliabile evitare di apportare modifiche al contenuto in fasi successive prima che tali modifiche siano state sottoposte alla convalida appropriata nello sviluppo o nel test.

Quando si esegue una distribuzione manuale, è possibile confrontare le fasi per identificare le modifiche al contenuto nella finestra di revisione delle modifiche. Questo approccio è particolarmente utile quando non si usa un repository Git remoto per il controllo del codice sorgente.

Usare le API REST di Power BI per eseguire la distribuzione

È possibile usare le API REST di Power BI per distribuire il contenuto usando una pipeline di distribuzione. Un vantaggio dell'uso delle API REST è il fatto che sia possibile automatizzare la distribuzione e integrarla con altri strumenti, ad esempio Azure Pipelines in Azure DevOps.

Distribuire con Azure Pipelines

Azure Pipelines consente di orchestrare la distribuzione tra tutte le fasi. Con questo approccio si usano le API REST di Fabric per distribuire e gestire il contenuto, usando diverse pipeline di Azure Pipelines, ad esempio pipeline di convalida e rilascio.

Prendere in considerazione l'uso di Azure Pipelines quando:

• Si vuole centralizzare l'orchestrazione della distribuzione dall'interno di Azure DevOps.
• I creatori di contenuti usano Azure DevOps per collaborare e per il controllo del codice sorgente.

Valutare un altro approccio rispetto ad Azure Pipelines quando:

• I creatori di contenuti non hanno familiarità con Azure DevOps o con le distribuzioni basate su codice.
• Il contenuto include tipi di elementi che non hanno una definizione supportata o un formato di file di origine, ad esempio i dashboard.

Esistono due approcci diversi per distribuire il contenuto con Azure Pipelines. Esse orchestrano le pipeline di distribuzione o distribuiscono il contenuto in un'area di lavoro senza una pipeline di distribuzione.

Orchestrare le pipeline di distribuzione di Fabric usando Azure Pipelines

In questo approccio, le pipeline di versione orchestrano la distribuzione del contenuto nelle aree di lavoro di test e produzione usando le pipeline di distribuzione. Il contenuto viene promosso tramite aree di lavoro di sviluppo, test e produzione in Fabric.

Il diagramma seguente illustra come orchestrare le pipeline di distribuzione da Azure Pipelines.

In sintesi, i creatori di contenuti pubblicano il contenuto nell'area di lavoro nella prima fase della pipeline di distribuzione. Quindi, un responsabile di release approva la distribuzione, che attiva una pipeline di Azure. Questa pipeline usa le API REST di Power BI per promuovere il contenuto tra le fasi, in modo che i metadati vengano distribuiti in un'altra area di lavoro. Uno dei vantaggi di questo approccio consiste nel fatto che è possibile orchestrare la distribuzione di più tipi di elementi Fabric tramite pipeline di distribuzione, perché alcuni tipi di elementi vengono sviluppati nel portale di Fabric e quindi non possono essere distribuiti solo da Azure Pipelines.

Distribuire il contenuto usando solo Azure Pipelines

È inoltre possibile distribuire contenuto in un'area di lavoro da Azure DevOps usando Azure Pipelines. Questo approccio non usa le pipeline di distribuzione. Usa invece pipeline di versione per distribuire file di origine o file di metadati usando le API REST di Fabric o Power BI o gli endpoint di lettura/scrittura XMLA. In genere, questi file vengono archiviati in un repository Git di Azure Repos.

Il diagramma seguente illustra come distribuire il contenuto usando solo Azure Pipelines.

In sintesi, i creatori di contenuti eseguono il commit e il push delle modifiche al contenuto in un repository Git remoto in Azure Repos. Questo contenuto viene usato da Azure Pipelines per la distribuzione. Dopo che il responsabile della release approva la distribuzione specifica, Azure Pipeline distribuirà il contenuto nell'area di lavoro usando le API REST di Power BI (ovvero per i file con estensione pbix), le API REST di Fabric (ovvero per le definizioni degli elementi) o gli endpoint XMLA (ovvero per i file model.bim). Esiste una pipeline di Azure separata per ogni area di lavoro.

Questo approccio non richiede capacità Fabric o licenze Premium quando si pubblicano solo file di Power BI Desktop con le API REST di Power BI. Tuttavia, comporta un maggiore sforzo e complessità di configurazione, perché è necessario gestire la distribuzione all'esterno di Power BI. I team di sviluppo che usano già DevOps per soluzioni di dati all'esterno di Power BI potrebbero avere familiarità con questo approccio. I team di sviluppo che usano questo approccio possono consolidare la distribuzione di soluzioni dati in Azure DevOps.

Distribuire con l'integrazione Git di Fabric

Quando si usa l'integrazione Git, è possibile sincronizzare rami diversi in aree di lavoro diverse anziché pubblicare o distribuire contenuto in modo esplicito. In questo modo, è possibile avere rami separati per aree di lavoro di sviluppo, test e produzione. In questo scenario, il ramo principale viene sincronizzato con l'area di lavoro di produzione. Distribuire quindi il contenuto tra aree di lavoro eseguendo una richiesta pull per unire il ramo di sviluppo al ramo di test (per distribuire nell'area di lavoro di test) o unire il ramo di test al ramo principale (per distribuire nell'area di lavoro di produzione).

Il diagramma seguente illustra come distribuire il contenuto usando l'integrazione Git di Fabric per sincronizzare i rami in aree di lavoro diverse. Per semplicità, il diagramma non include dettagli relativi alla diramazione o all'unione del contenuto.

In sintesi, i creatori di contenuti eseguono il commit e il push delle modifiche al contenuto in un repository Git remoto in Azure Repos. I creatori di contenuti aprono richieste pull per richiedere di unire le modifiche a un ramo specifico. A seconda della strategia di diramazione, rami diversi sono connessi ad aree di lavoro diverse. Dopo che le modifiche vengono unite a un ramo, i creatori di contenuti sincronizzano l'area di lavoro con il repository Git remoto per visualizzare le modifiche più recenti al contenuto in tale area di lavoro.

Si consideri questo approccio quando:

• Si vuole orchestrare la distribuzione tra aree di lavoro usando la strategia di diramazione e unione.
• Non si intende usare Azure Pipelines o pipeline di distribuzione Fabric per orchestrare le distribuzioni per ambienti di test e produzione.
• L'area di lavoro non contiene elementi o scenari non supportati.
• Il contenuto non ha etichette di riservatezza.

Nota

Esistono molti modi validi per distribuire il contenuto. Ad esempio, è possibile usare una combinazione dei diversi approcci descritti in questo articolo.

Ad esempio, è possibile distribuire il contenuto in un'area di lavoro di sviluppo usando una pipeline di Azure, il che consente di trarre vantaggio dalle funzionalità di integrazione continua e di eseguire test automatizzati, ad esempio usando l’analizzatore delle procedure consigliate. È quindi possibile distribuire il contenuto tra aree di lavoro usando l'integrazione Git o una pipeline di distribuzione di Fabric.

Scegliere l'approccio più adatto alle proprie esigenze e il modo in cui lavora il proprio team.

Decidere come gestire le attività post-distribuzione

Dopo la distribuzione, è necessario gestire varie attività post-distribuzione. Molte di queste attività possono essere gestite a livello di programmazione, ad esempio da una pipeline di Azure o da un notebook e dalle API REST di Power BI e Fabric. Ad esempio, è possibile impostare le credenziali dell'origine dati a livello di programmazione, gestire l'aggiornamento pianificato e attivare gli aggiornamenti dopo una distribuzione dei metadati. Tuttavia, alcune attività richiedono un intervento manuale, ad esempio una prima configurazione o l'aggiornamento di un'app Power BI.

Assicurarsi di identificare tutte le attività post-distribuzione pertinenti per il contenuto e di decidere come verranno gestite.

Dopo aver pianificato la distribuzione del contenuto, è consigliabile valutare come supportarlo e monitorarlo.

Elenco di controllo: quando si pianifica come distribuire il contenuto, le decisioni chiave e le azioni includono:

• Identificare le opzioni di distribuzione disponibili: a seconda delle licenze e dei contenuti, sono disponibili diverse opzioni per pubblicare il contenuto o alzarlo di livello tra aree di lavoro. Identificare se è possibile usare pipeline di distribuzione, Azure DevOps, l’integrazione Git, API REST di Fabric ed endpoint di lettura/scrittura XMLA.
• Decidere come pubblicare il contenuto: scegliere un approccio per pubblicare contenuti più adatti al flusso di lavoro e alle esigenze. Assicurarsi che questo approccio sia allineato alle altre strategie, ad esempio il modo in cui si tiene traccia e si gestiscono le modifiche.
• Decidere come alzare di livello il contenuto tra aree di lavoro: scegliere un approccio per distribuire contenuto dalle aree di lavoro di sviluppo a quelle di test e dalle aree di lavoro di test a quelle di produzione. Assicurarsi che questo approccio sia allineato alle altre strategie, ad esempio la modalità di pubblicazione del contenuto.
• Pianificare la strategia di rilascio: determinare se un individuo specifico sarà responsabile della revisione finale del contenuto prima di approvare una versione o una distribuzione. Assicurarsi che questo individuo sia a conoscenza dell’attività e delle operazioni da eseguire per proteggere il processo di distribuzione senza bloccare lo stato di avanzamento.
• Pianificare le attività successive alla distribuzione: assicurarsi di aver deciso un processo per eseguire attività come l'aggiornamento di un'app Power BI o l'aggiornamento di elementi di dati dopo una distribuzione di metadati. Valutare la possibilità di automatizzare questo processo usando le API REST di Fabric.
• Eseguire la prima configurazione degli strumenti e dei processi di distribuzione: assicurarsi di configurare l'accesso appropriato e che le autorizzazioni siano allineate alla configurazione dell'accesso al contenuto.
• Distribuire il contenuto nell'ambiente di produzione: quando è stata pianificata e configurata la distribuzione, distribuire il contenuto nell'ambiente di produzione.

Contenuto correlato

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