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

Questo articolo illustra come distribuire il contenuto come parte della gestione del ciclo di vita del contenuto. È destinato principalmente a:

• Amministratori dell'infrastruttura: amministratori responsabili della supervisione dell'infrastruttura nell'organizzazione. Gli amministratori dell'infrastruttura potrebbero dover collaborare con altri amministratori, ad esempio quelli che supervisionano Microsoft 365 o Azure DevOps.
• 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 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 dagli autori di contenuti che dagli utenti. Nella quarta fase si distribuisce il contenuto per gli utenti per usarlo.

Per condividere il contenuto di Power BI con i consumer, è necessario pubblicare (o distribuire) il contenuto in un'area di lavoro infrastruttura. 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 come gli utenti self-service possono distribuire il contenuto usando le pipeline di distribuzione di OneDrive for Work e School and Fabric.
• Pianificazione dell'implementazione di Power BI: scenario di utilizzo della pubblicazione di contenuti aziendali: questo articolo descrive come 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 promuovere 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 fa riferimento alla pubblicazione di contenuto come 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 dal computer locale a 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:

• Gli autori di contenuti preferiscono controllare manualmente la pubblicazione del contenuto nel portale di Fabric.
• Gli autori di contenuti usano Power BI Desktop per sviluppare e gestire il contenuto.
• Gli autori 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 agli autori 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, ad esempio 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 avanzato della gestione 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:

• Gli autori di contenuti preferiscono controllare manualmente la pubblicazione del contenuto nel portale di Fabric.
• Gli autori 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à infrastruttura.
• Gli autori di contenuti non hanno familiarità con Azure DevOps o Git.
• Il contenuto comprende solo modelli semantici.

Pubblicare con l'aggiornamento di OneDrive

OneDrive consente agli autori di contenuti self-service di pubblicare automaticamente modelli semantici o report in un'area di lavoro nel portale di Fabric usando l'aggiornamento di OneDrive. Gli autori di contenuti possono salvare i file di Power BI Desktop (con estensione 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 for Work e School 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:

• Gli autori di contenuti vogliono automatizzare la pubblicazione di contenuti nel portale di Fabric.
• Gli autori di contenuti non hanno familiarità con Azure DevOps o Git.
• Gli autori di contenuti eseguono il controllo della versione del contenuto usando OneDrive o SharePoint.
• Gli autori di contenuti salvano i modelli semantici e i report come file con estensione 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à di Infrastruttura che consente agli autori di contenuti di sincronizzare un ramo da un repository Git remoto a 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 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.

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 di Git, vedere Esercitazione: Gestione del ciclo di vita nei progetti Fabric e Power BI Desktop: Integrazione Git.

Prendere in considerazione l'uso di questo approccio quando:

• Gli autori di contenuti hanno familiarità con Azure DevOps e Git.
• Gli autori di contenuti usano Azure DevOps per la collaborazione e il controllo del codice sorgente.
• Gli autori di contenuti salvano i modelli semantici e i report come file di progetto di Power BI (con estensione pbip).
• Il contenuto verrà pubblicato in un'area di lavoro in una capacità infrastruttura.
• 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 decide 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 il 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 trovino nella capacità Fabric o Premium. Tuttavia, le API REST di Infrastruttura 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 Progetti di Power BI Desktop integrazione e pipeline di compilazione di Azure DevOps.

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

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

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

• API REST di Power BI: esistono diversi endpoint dell'API REST di Power BI che è possibile usare per distribuire il contenuto. Le API REST di Power BI supportano solo i tipi di elementi di Power BI.
  • Importa: è 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.
  • Distribuisci: è possibile distribuire gli elementi supportati, promuovendoli da un'area di lavoro a un'altra se sono fasi in una pipeline di distribuzione.
• API REST dell'infrastruttura: esistono diversi endpoint api REST di Infrastruttura che è possibile usare per distribuire il contenuto. Le API REST di Infrastruttura supportano sia i tipi di elementi di Power BI che di Infrastruttura.
  • Creazione: è possibile creare elementi supportati usando le API REST di Fabric insieme a una definizione di elemento valida.
  • Aggiornamento da Git: è possibile aggiornare un'area di lavoro con contenuto da 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). Ciò 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 o configurare alcuna configurazione 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 di essere pubblicati in un'area di lavoro di sviluppo. In genere, le modifiche in un ramo del repository remoto attivano la pipeline per convalidare tali modifiche con test automatizzati.

Esempi di test automatizzati includono l'analisi del modello di dati per individuare le violazioni delle regole delle procedure 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 serializzato 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 di Power BI (con estensione pbip) 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 attivati su richiesta o quando approvati. Le pipeline di versione di test e produzione distribuiscono il contenuto in un'area di lavoro di test o produzione, rispettivamente, dopo l'approvazione del rilascio. 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 responsabili delle versioni, 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. Può causare errori o interruzioni a causa di errori. 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à infrastruttura.
• I tipi di elementi di contenuto e gli scenari sono supportati dalle pipeline di distribuzione.

Considerare 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 a 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, è anche 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 è che è possibile collegare facoltativamente il contenuto connesso tra aree di lavoro e pipeline di distribuzione usando l'associazione automatica. In caso contrario, è identico al primo approccio.

Le pipeline di distribuzione sono uno strumento flessibile e semplice 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.

È anche consigliabile usare le 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 dal database di sviluppo, mentre il modello semantico nelle origini dell'area di lavoro di produzione 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 o gli errori di distribuzione non approvati.

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 causata da un utente che pubblica contenuto collegato alla fase sbagliata.

È possibile attivare le distribuzioni manualmente o a livello di codice 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 indietro quando le modifiche al contenuto esistono in una fase successiva, ma non in una versione precedente.

Attenzione

Quando si usano le pipeline di distribuzione, è consigliabile distribuire il contenuto in un'unica direzione, ad esempio dallo sviluppo al test alle aree di lavoro di 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 è che è 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 Infrastruttura per distribuire e gestire il contenuto, usando diverse pipeline di Azure Pipelines, ad esempio pipeline di convalida e versione.

Prendere in considerazione l'uso di Azure Pipelines quando:

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

Considerare un altro approccio rispetto ad Azure Pipelines quando:

• Gli autori di contenuti non hanno familiarità con Azure DevOps o 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. 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, gli autori di contenuti pubblicano il contenuto nell'area di lavoro nella prima fase della pipeline di distribuzione. Quindi, un responsabile di rilascio 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 di Infrastruttura tramite pipeline di distribuzione, perché alcuni tipi di elementi vengono sviluppati nel portale di Infrastruttura e quindi non possono essere distribuiti da azure Pipelines da soli.

Distribuire il contenuto usando solo Azure Pipelines

È anche 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 Infrastruttura 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, gli autori 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 versione 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à di infrastruttura o licenze Premium quando si pubblicano solo file di Power BI Desktop con le API REST di Power BI. Tuttavia, comporta un maggiore impegno di configurazione e complessità 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 nel ramo di test (da distribuire nell'area di lavoro di test) o unire il ramo di test nel ramo principale (da 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, gli autori di contenuti eseguono il commit e il push delle modifiche al contenuto in un repository Git remoto in Azure Repos. Gli autori di contenuti aprono richieste pull per richiedere di unire le modifiche in un ramo specifico. A seconda della strategia di diramazione, rami diversi sono connessi a aree di lavoro diverse. Dopo che le modifiche vengono unite in un ramo, gli autori 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.

Prendere in considerazione 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 di Infrastruttura per orchestrare le distribuzioni per testare 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, che consente di trarre vantaggio dalle funzionalità di integrazione continua e di eseguire test automatizzati, ad esempio usando Best Practice Analyzer. È 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 funziona il 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 codice, 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 codice, gestire l'aggiornamento pianificato e attivare gli aggiornamenti dopo una distribuzione dei metadati. Tuttavia, alcune attività richiedono un intervento manuale, ad esempio una configurazione per la prima volta 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 promuoverlo tra aree di lavoro. Identificare se è possibile usare pipeline di distribuzione, Azure DevOps, integrazione Git, API REST di Infrastruttura 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 come tenere traccia e gestire le modifiche.
• Decidere come alzare di livello il contenuto tra aree di lavoro: scegliere un approccio per distribuire contenuto dallo sviluppo alle aree di lavoro di test e dalle aree di lavoro di test alle aree di lavoro 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 utente sia a conoscenza di questa 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 di 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 Infrastruttura.
• 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.