Scenari di utilizzo di Power BI: Pubblicazione di contenuti aziendali

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.

Quando gli autori di contenuti collaborano per fornire soluzioni analitiche importanti per l'organizzazione, devono garantire una consegna tempestiva e affidabile dei contenuti ai consumer. I team tecnici affrontano questa sfida usando un processo denominato DevOps. DevOps consente ai team di automatizzare e ridimensionare i processi adottando procedure che migliorano e accelerano la distribuzione.

Nota

I team di dati che affrontano le stesse sfide possono anche esercitarsi su DataOps. DataOps si basa sui principi DevOps, ma DataOps include procedure aggiuntive specifiche per la gestione dei dati, ad esempio la garanzia della qualità dei dati e la governance. In questo articolo si fa riferimento a DevOps, ma tenere presente che i principi sottostanti possono essere applicati anche a DataOps.

Gli autori di contenuti e i consumer traggono diversi vantaggi quando si adottano procedure DevOps per pubblicare contenuti di Power BI. I punti seguenti sono una panoramica generale del funzionamento di questo processo.

1. Sviluppare contenuto ed eseguire il commit del lavoro in un repository remoto: gli autori di contenuti sviluppano la propria soluzione nel proprio computer. Eseguono il commit e salvano il lavoro in un repository remoto a intervalli regolari durante lo sviluppo. Un repository remoto contiene la versione più recente della soluzione ed è accessibile all'intero team di sviluppo.
2. Collaborare e gestire le modifiche al contenuto usando il controllo della versione: altri autori di contenuti possono apportare revisioni alla soluzione creando un ramo. Un ramo è una copia di un repository remoto. Quando queste revisioni sono pronte e approvate, il ramo viene unito alla versione più recente della soluzione. Vengono rilevate tutte le revisioni della soluzione. Questo processo è noto come controllo della versione (o controllo del codice sorgente).
3. Distribuire e promuovere il contenuto usando le pipeline: nello scenario di utilizzo della pubblicazione di contenuti self-service il contenuto viene promosso (o distribuito) tramite aree di lavoro di sviluppo, test e produzione usando le pipeline di distribuzione di Power BI. Le pipeline di distribuzione di Power BI possono promuovere il contenuto alle aree di lavoro di Power BI Premium manualmente usando l'interfaccia utente o a livello di codice usando le API REST. Al contrario, la pubblicazione di contenuti aziendali (l'obiettivo di questo scenario di utilizzo) promuove il contenuto usando Azure Pipelines. Azure Pipelines è un servizio Azure DevOps che automatizza test, gestione e distribuzione del contenuto usando una serie di passaggi a livello di codice personalizzati. Nello scenario di utilizzo della pubblicazione di contenuti aziendali, queste pipeline possono anche essere definite pipeline di integrazione e distribuzione continua (o CI/CD). Queste pipeline integrano in modo frequente e automatico le modifiche e semplificano la pubblicazione del contenuto.

Importante

A volte questo articolo si riferisce a Power BI Premium o alle relative sottoscrizioni di capacità (SKU P). Tenere presente che Microsoft sta attualmente consolidando le opzioni di acquisto e ritirando gli SKU di Power BI Premium per capacità. I clienti nuovi ed esistenti devono invece prendere in considerazione l'acquisto di sottoscrizioni con capacità Fabric (SKU F).

Per altre informazioni, vedere Aggiornamento importante disponibile per le licenze Power BI Premium e Domande frequenti su Power BI Premium.

DevOps supporta un approccio maturo e sistematico alla gestione e alla pubblicazione dei contenuti. Consente ai creatori di contenuti di collaborare alle soluzioni e garantisce la distribuzione rapida e affidabile dei contenuti ai consumer. Quando si rispettano le procedure DevOps, si trae vantaggio da flussi di lavoro semplificati, meno errori ed esperienze migliorate per gli autori di contenuti e i consumer di contenuti.

È possibile configurare e gestire le procedure DevOps per la soluzione Power BI usando Azure DevOps. Negli scenari aziendali è possibile automatizzare la pubblicazione del contenuto con Azure DevOps e le API REST di Power BI in tre modi diversi.

• API REST di Power BI con pipeline di distribuzione di Power BI: è possibile importare contenuto nelle aree di lavoro di sviluppo e usare le pipeline di distribuzione per distribuire il contenuto tramite aree di lavoro di test e produzione. È comunque possibile controllare la distribuzione da Azure DevOps e usare le API REST di Power BI per gestire le pipeline di distribuzione anziché i singoli elementi di contenuto. È anche possibile usare l'endpoint XMLA per distribuire i metadati del modello di dati anziché un file di Power BI Desktop (con estensione pbix) con Azure DevOps. Questi metadati consentono di tenere traccia delle modifiche a livello di oggetto usando il controllo della versione. Sebbene sia più affidabile e più semplice da gestire, questo approccio richiede licenze Premium e un impegno di scripting medio per configurare l'importazione e la distribuzione del contenuto con le API REST di Power BI. Usare questo approccio quando si vuole semplificare la gestione del ciclo di vita del contenuto con le pipeline di distribuzione e si ha una licenza Premium. Gli endpoint XMLA e le pipeline di distribuzione di Power BI sono funzionalità Premium.
• API REST di Power BI: è anche possibile importare contenuto in aree di lavoro di sviluppo, test e produzione usando Azure DevOps e solo le API REST di Power BI. Questo approccio non richiede licenze Premium, ma comporta un'elevata attività di scripting e configurazione, perché la distribuzione viene gestita all'esterno di Power BI. Usare questo approccio quando si vuole distribuire il contenuto di Power BI centralmente da Azure DevOps o quando non si ha una licenza Premium. Per un confronto visivo tra i primi due approcci, vedere il diagramma di flusso degli approcci alla pipeline di versione.
• Strumenti di automazione di Power BI con pipeline di distribuzione di Power BI: è possibile usare l'estensione Azure DevOps degli strumenti di automazione di Power BI per gestire le pipeline di distribuzione anziché le API REST di Power BI. Questo approccio è un'alternativa alla prima opzione, che usa le API REST di Power BI con le pipeline di distribuzione di Power BI. L'estensione degli strumenti di automazione di Power BI è uno strumento open source. Consente di gestire e pubblicare contenuto da Azure DevOps senza la necessità di scrivere script di PowerShell. Usare questo approccio quando si vogliono gestire le pipeline di distribuzione da Azure DevOps con un lavoro di scripting minimo e quando si ha una capacità Premium.

Questo articolo è incentrato sulla prima opzione, che usa le API REST di Power BI con le pipeline di distribuzione di Power BI. Descrive come usare Azure DevOps per configurare le procedure DevOps. Descrive anche come usare Azure Repos per i repository remoti e automatizzare test, integrazione e recapito dei contenuti con Azure Pipelines. Azure DevOps non è l'unico modo per configurare la pubblicazione di contenuti aziendali, ma una semplice integrazione con Power BI lo rende una scelta ottimale.

Nota

Questo scenario di utilizzo è uno degli scenari di gestione e distribuzione dei contenuti. Per brevità, alcuni aspetti descritti nell'argomento scenari di collaborazione e distribuzione dei contenuti non sono trattati in questo articolo. Per una copertura completa, leggere prima questi articoli.

Suggerimento

Microsoft Fabric offre altre opzioni per la pubblicazione di contenuti aziendali tramite l'integrazione Git di Fabric. L'integrazione Git consente di collegare un'area di lavoro di Fabric a un ramo nel repository remoto di Azure Repos. Il contenuto salvato in tale ramo verrà sincronizzato automaticamente con l'area di lavoro, come se il contenuto fosse stato pubblicato nell'area di lavoro. Viceversa, gli autori di contenuti possono eseguire il commit e il push delle modifiche dall'area di lavoro di Fabric al repository remoto.

L'integrazione Git può semplificare la collaborazione e la pubblicazione di contenuti, ma richiede una pianificazione maggiore per l'uso delle aree di lavoro di Fabric e la strategia di diramazione. Per altre informazioni su come configurare e usare l'integrazione Git di Fabric, vedere Attività iniziali per l'integrazione Git o Esercitazione: Gestione del ciclo di vita end-to-end.

Diagramma dello scenario

Il diagramma seguente illustra una panoramica generale delle azioni utente più comuni e dei componenti di Power BI che supportano la pubblicazione di contenuti aziendali. L'obiettivo è l'uso di Azure DevOps per gestire e pubblicare contenuti a livello di codice su larga scala tramite aree di lavoro di sviluppo, test e produzione nel servizio Power BI.

Suggerimento

È consigliabile scaricare il diagramma dello scenario se si vuole incorporarlo nella presentazione, nella documentazione o nel post di blog oppure stamparlo come poster a parete. Poiché si tratta di un'immagine SVG (Scalable Vector Graphics), è possibile aumentarla o ridurla senza perdita di qualità.

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

Articolo	Descrizione
	Gli autori di contenuti sviluppano modelli di dati usando Power BI Desktop o Tabular Editor e sviluppano report usando Power BI Desktop. Gli autori di contenuti salvano il lavoro in un repository locale durante lo sviluppo.
	Gli autori di contenuti possono clonare un repository remoto per ottenere una copia locale di tale contenuto.
	Alcune origini dati possono richiedere un gateway dati locale o un gateway di rete virtuale per l'aggiornamento dei dati, ad esempio quelli che risiedono all'interno di una rete aziendale privata.
	Gli autori di contenuti eseguono regolarmente il commit e il push delle modifiche in un repository remoto durante lo sviluppo usando un client Git come Visual Studio Code. Nel diagramma il repository remoto è Azure Repos.
	Altri creatori di contenuti usano Azure Repos per tenere traccia delle modifiche con il controllo della versione. Collaborano eseguendo il commit delle modifiche in rami separati.
	Modifiche al contenuto nel repository remoto attivano Azure Pipelines. Una pipeline di convalida è la prima pipeline attivata. La pipeline di convalida esegue test automatizzati per convalidare il contenuto prima della pubblicazione.
	Il contenuto che supera la pipeline di convalida attiva una pipeline di compilazione successiva. La pipeline di compilazione prepara il contenuto per la pubblicazione nel servizio Power BI. Il processo fino a questo punto viene in genere definito integrazione continua (CI).
	Il contenuto viene pubblicato e distribuito usando le pipeline di versione. Le pipeline di versione usano le API REST di Power BI o l'endpoint XMLA dell'area di lavoro per importare il contenuto a livello di codice nel servizio Power BI. La distribuzione tramite pipeline di versione viene in genere definita distribuzione continua (CD).
	Un gestore delle versioni controlla la distribuzione per testare e creare aree di lavoro di produzione usando un'approvazione della versione di Azure Pipelines. Nella pubblicazione di contenuti aziendali, un gestore delle versioni pianifica e coordina in genere la versione del contenuto in ambienti di test e produzione. Coordina e comunica con creatori di contenuti, stakeholder e utenti.
	Una pipeline di versione pubblica il contenuto nell'area di lavoro di sviluppo o promuove il contenuto dall'area di lavoro di sviluppo a quella di test o da quella di test a quella di produzione.
	Gli autori di contenuti che lavorano in un'area di lavoro con la modalità di licenza della capacità di Fabric possono usare l'integrazione Git. Con l'integrazione con Git, gli autori di contenuti possono lavorare in un'area di lavoro privata durante lo sviluppo. L'autore del contenuto sincronizza un ramo remoto (in genere un ramo di funzionalità specifico o un ramo di bug) da Azure Repos all'area di lavoro privata. Le modifiche al contenuto vengono sincronizzate tra il ramo remoto in Azure Repos e l'area di lavoro. In questo scenario, gli autori di contenuti non devono usare Azure Pipelines per pubblicare il contenuto. Gli autori di contenuti possono anche eseguire regolarmente il commit e il push delle modifiche dall'area di lavoro dopo la pubblicazione. Quando sono pronti, gli autori di contenuti possono effettuare una richiesta pull per unire le modifiche apportate al ramo principale.
	Quando si usa l'integrazione Git, l'area di lavoro di sviluppo si sincronizza con il ramo principale per ottenere le versioni più recenti del contenuto. Questo contenuto include tutte le modifiche apportate dalle richieste pull che un responsabile delle versioni esamina, approva e unisce.
	Le aree di lavoro sono impostate su Capacità Fabric, Capacità Premium, Premium per utente o Modalità di licenza incorporata, per consentire l'uso delle pipeline di distribuzione di Power BI e dell'endpoint di lettura/scrittura XMLA.
	Un amministratore della pipeline di distribuzione configura la pipeline di distribuzione di Power BI con tre fasi: sviluppo, test e produzione. Ogni fase è allineata a un'area di lavoro separata nel servizio Power BI. Le impostazioni di distribuzione e l'accesso vengono impostati per la pipeline di distribuzione.
	L'area di lavoro sviluppo contiene le versioni più recenti del contenuto, incluse tutte le modifiche approvate e unite. Dopo l'approvazione, una pipeline di versione distribuisce il contenuto dall'area di lavoro di sviluppo a quella di test.
	I revisori all'interno dell'area di lavoro di test eseguono test e controllo di qualità sul contenuto. Dopo l'approvazione, una pipeline di versione distribuisce il contenuto dall'area di lavoro di test a quella di produzione. Quando si usa l'integrazione Git con le pipeline di distribuzione, l'area di lavoro di test non viene sincronizzata con alcun ramo.
	Una volta completata la pipeline di distribuzione, gli autori di contenuti eseguono manualmente le attività post-distribuzione. Le attività possono includere la configurazione dell'aggiornamento dati pianificato o l'aggiornamento di un'app Power BI per l'area di lavoro di produzione. Quando si usa l'integrazione Git con le pipeline di distribuzione, l'area di lavoro di produzione non viene sincronizzata con alcun ramo.
	I visualizzatori del contenuto accedono al contenuto usando l'area di lavoro di produzione o un'app Power BI.

Suggerimento

È consigliabile esaminare anche gli scenari d'uso di pubblicazione di contenuti self-service e di gestione avanzata dei modelli di dati. Lo scenario di utilizzo della pubblicazione di contenuti aziendali si basa sui concetti introdotti da questi scenari.

Punti chiave

Di seguito sono riportati alcuni punti chiave da sottolineare relativamente allo scenario di pubblicazione dei contenuti aziendali.

Controllo della versione

Il rilevamento delle modifiche durante il ciclo di vita del contenuto è importante per garantire la distribuzione stabile e coerente del contenuto ai consumer. In questo scenario di utilizzo, gli autori di contenuti e i proprietari gestiscono le modifiche al contenuto in un repository remoto 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 procedura consente una migliore collaborazione e una gestione efficace della cronologia delle versioni. Il controllo della versione presenta vantaggi per gli autori di contenuti, inclusa la possibilità di eseguire il rollback o unire le modifiche.

Gli autori di contenuti sviluppano in genere modelli di dati in Tabular Editor per supportare un migliore controllo della versione. A differenza di un modello di dati sviluppato in Power BI Desktop, un modello di dati sviluppato in Tabular Editor viene salvato in formato di metadati leggibili. Questo formato abilita il controllo della versione a livello di oggetto del modello di dati. È consigliabile usare il controllo della versione a livello di oggetto quando si collabora con più persone nello stesso modello di dati. Per altre informazioni, vedere lo scenario di utilizzo di gestione avanzata dei modelli di dati. Non è possibile visualizzare le modifiche apportate in un file di Power BI Desktop (con estensione pbix), ad esempio la definizione del report o il modello di dati. Ad esempio, non è possibile tenere traccia delle modifiche apportate a una pagina del report, come gli oggetti visivi usati, le relative posizioni e i mapping dei campi o la formattazione.

I creatori di contenuti archiviano i file di metadati del modello di dati e i file con estensione pbix in un repository remoto centrale, ad esempio Azure Repos. Questi file sono curati da un proprietario tecnico. Mentre un creatore di contenuti sviluppa una soluzione, un proprietario tecnico è responsabile della gestione della soluzione e della revisione delle modifiche, nonché dell'unione in un'unica soluzione. Azure Repos offre opzioni sofisticate per tenere traccia e gestire le modifiche. Questo approccio è diverso dall'approccio descritto nello scenario di utilizzo della pubblicazione di contenuti self-service, in cui l'autore usa l'archiviazione di OneDrive con il rilevamento delle versioni. La gestione di un repository ben curato e documentato è essenziale perché è alla base dell'intero contenuto e collaborazione.

Ecco alcune considerazioni chiave che consentono di configurare un repository remoto per il controllo della versione.

• Ambito: definire chiaramente l'ambito del repository. Idealmente, l'ambito del repository è identico all'ambito delle aree di lavoro downstream e delle app usate per distribuire contenuto ai consumer.
• Accesso: è necessario configurare l'accesso al repository 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 al repository.
• Documentazione: aggiungere file di testo al repository per documentarne lo scopo, la proprietà, l'accesso e i processi definiti. Ad esempio, la documentazione può descrivere come eseguire lo staging e il commit delle modifiche.
• Strumenti: per eseguire il commit e il push delle modifiche in un repository remoto, gli autori di contenuti necessitano di un client Git come Visual Studio o Visual Studio Code. 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.

Nota

È consigliabile usare Archiviazione file di grandi dimensioni (LFS) Git se si prevede di eseguire il commit di file (con estensione pbix) di Power BI Desktop. Git LFS offre opzioni avanzate per la gestione dei file in cui le modifiche non sono visibili (file non modificabili), ad esempio un file con estensione pbix. Ad esempio, è possibile usare il blocco dei file per impedire modifiche simultanee a un report di Power BI durante lo sviluppo. Git LFS, tuttavia, ha una propria configurazione e client.

Collaborazione con Azure DevOps

Man mano che una soluzione aumenta nell'ambito e nella complessità, potrebbe essere necessario che più creatori di contenuti e proprietari lavorino in collaborazione. Gli autori di contenuti e i proprietari comunicano e collaborano in un hub centrale organizzato usando Azure DevOps.

Per collaborare e comunicare in Azure DevOps, è possibile usare i servizi di supporto.

• Azure Boards: i proprietari del contenuto usano le Boards per tenere traccia degli elementi di lavoro. Gli elementi di lavoro vengono assegnati a un singolo sviluppatore del team e descrivono problemi, bug o funzionalità nella soluzione e gli stakeholder corrispondenti.
• Wiki di Azure: gli autori di contenuti condividono informazioni con il proprio team per comprendere e contribuire alla soluzione.
• Azure Repos: gli autori di contenuti tengono traccia delle modifiche nel repository remoto e le uniscono in una singola soluzione.
• Azure Pipelines: i proprietari della pipeline configurano la logica a livello di codice per distribuire la soluzione, automaticamente o su richiesta.

Diagramma di flusso di collaborazione

Il diagramma seguente illustra una panoramica generale di un esempio di come Azure DevOps abilita la collaborazione nello scenario di utilizzo della pubblicazione di contenuti aziendali. Questo diagramma si concentra sull'uso di Azure DevOps per creare un processo di pubblicazione del contenuto strutturato e documentato.

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

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

Per elaborare, gli autori di contenuti ottengono la collaborazione usando una strategia di diramazione. Una strategia di diramazione è il modo in cui gli autori di contenuti creano, usano e uniscono rami per apportare e gestire in modo efficace le modifiche al contenuto. I singoli creatori di contenuti lavorano in isolamento nel repository locale. Quando sono pronti, combinano le modifiche come singola soluzione nel repository remoto. Gli autori di contenuti devono definire l'ambito del proprio lavoro in rami collegandoli agli elementi di lavoro per sviluppi, miglioramenti o correzioni di bug specifici. Ogni creatore di contenuti crea il proprio ramo del repository remoto per il proprio ambito di lavoro. Viene eseguito il commit del lavoro svolto sulla soluzione locale e viene eseguito il push in una versione del ramo nel repository remoto con un messaggio di commit. Un messaggio di commit descrive le modifiche apportate in tale commit.

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

Raccomandazioni per la collaborazione

È consigliabile definire un processo strutturato che stabilisca in che modo i creatori di contenuti devono collaborare. Assicurarsi di determinare:

• Modalità di definizione dell'ambito del lavoro e modalità di creazione, denominazione e uso dei rami.
• Modalità di raggruppamento delle modifiche e relativa descrizione nei messaggi di commit da parte degli autori.
• Chi sia responsabile della revisione e dell'approvazione delle richieste pull.
• Modalità di risoluzione dei conflitti di unione.
• Modalità di unione delle modifiche apportate in rami diversi in un singolo ramo.
• Modalità di test del contenuto e chi debba eseguire il test prima della distribuzione del contenuto.
• Modalità e tempistiche di distribuzione delle modifiche nelle aree di lavoro di sviluppo, test e produzione.
• Modalità e tempistiche di esecuzione del rollback delle modifiche o delle versioni distribuite della soluzione.

Importante

Il valore fornito da DevOps è direttamente proporzionale alla conformità ai processi che ne definiscono l'uso.

Una collaborazione efficace dipende da un processo ben definito. È importante descrivere e documentare chiaramente il flusso di lavoro di sviluppo end-to-end. Assicurarsi che le strategie e i processi selezionati siano allineati alle procedure esistenti nel team e, in caso contrario, come gestire il cambiamento. Assicurarsi inoltre che i processi siano chiari e comunicati a tutti i membri del team e agli stakeholder. Assicurarsi che i membri del team e gli stakeholder che non hanno familiarità con i processi vengano addestrati per l'adozione e che apprezzino il valore dell'adozione di DevOps.

API REST di Power BI

Si sviluppa logica a livello di codice per importare e distribuire contenuto da Azure DevOps usando le API REST di Power BI. I file di Power BI (con estensione pbix) vengono importati in un'area di lavoro usando un'operazione di importazione. Si usa un'operazione della pipeline per distribuire una parte di contenuto o tutto il contenuto nelle aree di lavoro di test o di produzione usando le pipeline di distribuzione di Power BI. La logica programmatica è definita in Azure Pipelines.

È consigliabile usare un'entità servizio per chiamare le API REST di Power BI nelle pipeline. Un'entità servizio è destinata alle attività automatiche e automatizzate e non si basa sulle credenziali utente. Tuttavia, alcuni elementi e attività non sono supportati dalle API REST di Power BI o quando si usa un'entità servizio, ad esempio i flussi di dati.

Quando si usa un'entità servizio, assicurarsi di gestire attentamente le autorizzazioni. L'obiettivo deve essere quello di seguire il principio dei privilegi minimi. È necessario impostare autorizzazioni sufficienti per l'entità servizio senza autorizzazioni di over provisioning. Usare Azure Key Vault o un altro servizio che archivia in modo sicuro i segreti e le credenziali dell'entità servizio.

Attenzione

Se si dispone di un modello di dati salvato come formato di metadati leggibili, non può essere pubblicato usando le API REST di Power BI. È invece necessario pubblicarlo usando l'endpoint XMLA. È possibile pubblicare file di metadati usando strumenti di terze parti come l'interfaccia della riga di comando di Tabular Editor. È anche possibile pubblicare i file di metadati a livello di codice usando lo sviluppo .NET personalizzato. Lo sviluppo di una soluzione personalizzata richiede più impegno, poiché è necessario usare l'estensione TOM (Microsoft Tabular Object Model) delle librerie client AMO (Analysis Management Object).

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. I proprietari della pipeline possono personalizzare i trigger, i passaggi e le funzionalità per soddisfare le esigenze di distribuzione. Di conseguenza, il numero e i tipi di pipeline variano a seconda dei requisiti della soluzione. Ad esempio, una pipeline di Azure può eseguire test automatizzati o modificare i parametri del modello di dati prima di una distribuzione.

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 tutte e tre queste 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 Power BI predefinite. Ad esempio, non è necessario avere una pipeline di convalida; è possibile usare solo pipeline di compilazione e di versione.

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 (descritto nel diagramma delle pipeline di versione). Una pipeline di compilazione può anche apportare altre 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 Power BI Desktop (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.

Esistono due approcci diversi per pubblicare contenuto con pipeline di test e versione. Promuovono il contenuto usando una pipeline di distribuzione di Power BI o pubblicano il contenuto nel servizio Power BI da Azure DevOps.

Il diagramma seguente illustra il primo approccio. 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 di Power BI. Il contenuto viene promosso tramite aree di lavoro di sviluppo, test e produzione in Power BI. Anche se questo approccio è più affidabile e più semplice da gestire, richiede licenze Premium.

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

Articolo	Descrizione
	Nel primo approccio, le pipeline di versione pubblicano il contenuto usando l'endpoint XMLA e le API REST di Power BI con le pipeline di distribuzione di Power BI. Il contenuto viene pubblicato e quindi promosso tramite aree di lavoro di sviluppo, test e produzione. Le pipeline di distribuzione di Power BI e l'endpoint di lettura/scrittura XMLA sono funzionalità Premium.
	Un'unione di rami riuscita o il completamento di una pipeline upstream attiva la pipeline di compilazione. La pipeline di compilazione prepara quindi il contenuto per la pubblicazione e attiva la pipeline di versione di sviluppo.
	La pipeline di versione di sviluppo pubblica il contenuto nell'area di lavoro di sviluppo usando l'endpoint XMLA (per i metadati del modello di dati) o le API REST di Power BI (per i file di Power BI Desktop, che possono contenere modelli di dati e report). La pipeline di sviluppo usa l'interfaccia della riga di comando di Tabular Editor per distribuire i metadati del modello di dati usando l'endpoint XMLA.
	Un'approvazione del rilascio o un trigger su richiesta attivano la pipeline di versione di test.
	La pipeline di versione di test distribuisce il contenuto usando le operazioni di distribuzione dell'API REST di Power BI, che eseguono la pipeline di distribuzione di Power BI.
	La pipeline di distribuzione di Power BI promuove il contenuto dall'area di lavoro di sviluppo all'area di lavoro di test. Dopo la distribuzione, la pipeline di versione esegue attività post-distribuzione usando le API REST di Power BI (non illustrate nel diagramma).
	Un'approvazione del rilascio o un trigger su richiesta attivano la pipeline di versione di produzione.
	La pipeline di versione di produzione distribuisce il contenuto usando le operazioni di distribuzione dell'API REST di Power BI, che eseguono la pipeline di distribuzione di Power BI.
	La pipeline di distribuzione di Power BI promuove il contenuto dall'area di lavoro di test all'area di lavoro di produzione. Dopo la distribuzione, la pipeline di versione esegue attività post-distribuzione usando le API REST di Power BI (non illustrate nel diagramma).

Il diagramma seguente illustra il secondo approccio. Questo approccio non usa le pipeline di distribuzione. Usa invece pipeline di versione per pubblicare il contenuto nelle aree di lavoro di test e di produzione da Azure DevOps. In particolare, questo secondo approccio non richiede licenze Premium quando si pubblicano solo file di Power BI Desktop con le API REST di Power BI. 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.

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

Articolo	Descrizione
	Nel secondo approccio, le pipeline di versione pubblicano il contenuto usando solo l'endpoint XMLA e le API REST di Power BI. Il contenuto viene pubblicato nelle aree di lavoro di sviluppo, test e produzione.
	Un'unione di rami riuscita o il completamento di una pipeline upstream attiva la pipeline di compilazione. La pipeline di compilazione prepara quindi il contenuto per la pubblicazione e attiva la pipeline di versione di sviluppo.
	La pipeline di versione di sviluppo pubblica il contenuto nell'area di lavoro di sviluppo usando l'endpoint XMLA (per i metadati del modello di dati) o le API REST di Power BI (per i file di Power BI Desktop, che possono contenere modelli di dati e report). La pipeline di sviluppo usa l'interfaccia della riga di comando di Tabular Editor per distribuire i metadati del modello di dati usando l'endpoint XMLA.
	Un'approvazione del rilascio o un trigger su richiesta attivano la pipeline di versione di test.
	La pipeline di versione di sviluppo pubblica il contenuto nell'area di lavoro di test usando l'endpoint XMLA (per i metadati del modello di dati) o le API REST di Power BI (per i file di Power BI Desktop, che possono contenere modelli di dati e report). La pipeline di sviluppo usa l'interfaccia della riga di comando di Tabular Editor per distribuire i metadati del modello di dati usando l'endpoint XMLA. Dopo la distribuzione, la pipeline di versione esegue attività post-distribuzione usando le API REST di Power BI (non illustrate nel diagramma).
	Un'approvazione del rilascio o un trigger su richiesta attivano la pipeline di versione di produzione.
	La pipeline di versione di sviluppo pubblica il contenuto nell'area di lavoro di produzione usando l'endpoint XMLA (per i metadati del modello di dati) o le API REST di Power BI (per i file di Power BI Desktop, che possono contenere modelli di dati e report). La pipeline di sviluppo usa l'interfaccia della riga di comando di Tabular Editor per distribuire i metadati del modello di dati usando l'endpoint XMLA. Dopo la distribuzione, la pipeline di versione esegue attività post-distribuzione usando le API REST di Power BI (non illustrate nel diagramma).

Le pipeline di versione devono gestire le attività successive alla distribuzione. Queste attività possono includere l'impostazione delle credenziali del modello semantico o l'aggiornamento dell'app Power BI per le aree di lavoro di test e produzione. È consigliabile configurare le notifiche per informare le persone pertinenti sulle attività di distribuzione.

Suggerimento

L'uso di un repository per il controllo della versione consente agli autori di contenuti di creare un processo di rollback. Il processo di rollback può invertire l'ultima distribuzione ripristinando la versione precedente. Prendere in considerazione la creazione di un set separato di Azure Pipelines che è possibile attivare per eseguire il rollback delle modifiche di produzione. Valutare attentamente i processi e le approvazioni necessari per avviare un rollback. Assicurarsi che questi processi siano documentati.

Pipeline di distribuzione di Power BI

Una pipeline di distribuzione di Power BI è costituita da tre fasi: sviluppo, test e produzione. Si assegna una singola area di lavoro di Power BI a ogni fase della pipeline di distribuzione. Quando si verifica una distribuzione, la pipeline di distribuzione promuove gli elementi di Power BI da un'area di lavoro a un'altra.

Una pipeline di versione di Azure Pipelines usa le API REST di Power BI per distribuire il contenuto usando una pipeline di distribuzione di Power BI. 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 utenti della pipeline possano visualizzare la cronologia di distribuzione e confrontare il contenuto.

Suggerimento

Quando si separano le aree di lavoro dati dalle aree di lavoro per la creazione di report, è consigliabile usare Azure Pipelines per orchestrare la pubblicazione del contenuto con più pipeline di distribuzione di Power BI. Il modello semantico viene prima distribuito e poi aggiornato. Infine, i report vengono distribuiti. Questo approccio consente di semplificare la distribuzione.

Licenze Premium

Le pipeline di distribuzione di Power BI e l'endpoint di lettura/scrittura XMLA sono funzionalità Premium. Queste funzionalità sono disponibili con capacità Power BI Premium e Power BI Premium per utente (PPU).

PPU è un modo conveniente per gestire la pubblicazione di contenuti aziendali per le aree di lavoro di sviluppo e test, che in genere hanno pochi utenti. Questo approccio offre il vantaggio di isolare i carichi di lavoro di sviluppo e test dai carichi di lavoro di produzione.

Nota

È comunque possibile configurare la pubblicazione di contenuti aziendali senza una licenza Premium, come descritto dal secondo approccio nella sezione relativa alla pipeline di versione. Nel secondo approccio si usa Azure Pipelines per gestire la distribuzione dei file di Power BI Desktop nelle aree di lavoro di sviluppo, test e produzione. Tuttavia, non è possibile distribuire i metadati del modello usando l'endpoint XMLA perché non è possibile pubblicare un modello semantico di formato di metadati con le API REST di Power BI. Inoltre, non è possibile promuovere il contenuto tramite ambienti con pipeline di distribuzione senza una licenza Premium.

Configurazione del gateway

In genere, è necessario un gateway dati quando si accede a origini dati che si trovano all'interno della rete organizzativa privata o di una rete virtuale. I due scopi di un gateway sono aggiornare i dati importati e visualizzare un report che esegue query su una connessione dinamica o un modello semantico DirectQuery (non illustrato nel diagramma dello scenario).

Quando si usano più ambienti, è comune configurare connessioni di sviluppo, test e produzione a sistemi di origine diversi. In questo caso, usare le regole dell'origine dati e le regole dei parametri per gestire i valori che differiscono tra gli ambienti. È possibile usare Azure Pipelines per gestire i gateway usando le operazioni del gateway delle API REST di Power BI.

Nota

Un gateway dati centralizzato in modalità standard è fortemente consigliato rispetto ai gateway in modalità personale. In modalità standard, il gateway dati supporta le operazioni di connessione dinamica e DirectQuery, oltre alle operazioni di aggiornamento dati pianificate.

Panoramica del sistema

Il log attività registra gli eventi che si verificano nel servizio Power BI. Gli amministratori di Power BI possono usare il log attività per controllare le attività di distribuzione.

È possibile usare le API di analisi dei metadati di Power BI per creare un inventario tenant. I risultati dell'API sono utili per verificare quali elementi sono stati distribuiti in ogni area di lavoro, per controllare la derivazione e per convalidare le impostazioni di sicurezza.

È disponibile anche un log di controllo all'interno di Azure DevOps, che si trova all'esterno del servizio Power BI. Gli amministratori di Azure DevOps possono usare il log di controllo per esaminare le attività nei repository e nelle pipeline remote.

Contenuto correlato

Per altri scenari utili che consentono di prendere decisioni di implementazione di Power BI, vedere l'articolo Scenari di utilizzo di Power BI.