Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In questa esercitazione, viene illustrato l'intero processo di caricamento dei dati nell'area di lavoro e l'uso delle pipeline di distribuzione insieme all'integrazione Git per collaborare con altri utenti nello sviluppo, nel test e nella pubblicazione dei dati e dei report.
Nota
Alcuni elementi di integrazione Git sono in fase di anteprima. Per altre informazioni, vedere l'elenco degli elementi supportati.
Prerequisiti
Per integrare Git con l'area di lavoro di Microsoft Fabric, è necessario configurare i prerequisiti seguenti per Fabric e Git.
Prerequisiti per il tessuto
Per accedere alla funzionalità di integrazione Git, è necessaria una Fabric capacity. Per usare tutti gli elementi Fabric supportati, è necessaria una capacità infrastruttura. Se non è ancora disponibile, iscriversi per ottenere una versione di valutazione gratuita. I clienti che hanno già una capacità Power BI Premium possono usare tale capacità, ma tenere presente che determinati SKU di Power BI supportano solo gli elementi di Power BI.
Inoltre, le opzioni del tenant seguenti devono essere abilitate dal portale di amministrazione:
- Gli utenti possono creare elementi di Fabric
- Gli utenti possono sincronizzare gli elementi dell'area di lavoro con i repository Git personali
- Creare aree di lavoro (solo se si desidera espandere in una nuova area di lavoro).
- Gli utenti possono sincronizzare gli elementi dell'area di lavoro con i repository GitHub: solo per gli utenti di GitHub
Queste opzioni possono essere abilitate dall'amministratore tenant, dall'amministratore della capacità o dall'amministratore dell'area di lavoro, a seconda delle impostazioni dell'organizzazione.
Prerequisiti Git
L'integrazione Git è attualmente supportata per Azure DevOps e GitHub. Per usare l'integrazione di Git con l'area di lavoro di Fabric, è necessario quanto segue in Azure DevOps o GitHub:
- Un account Azure attivo associato allo stesso utente che utilizza l'area di lavoro Fabric. Creare un account gratuito.
- Scaricare il file FoodSales.pbix in un repository Git che è possibile modificare. Questo file di esempio viene usato in questa esercitazione. In alternativa, è possibile usare il proprio modello semantico e report, se si preferisce.
Se si dispone già dei diritti di amministratore per un'area di lavoro con i dati, è possibile passare al passaggio 3.
Fase 1: Creare un'area di lavoro Premium
Per creare una nuova area di lavoro e assegnarle una licenza:
Nella barra di spostamento sinistra dell'esperienza di Power BI selezionare Aree di > lavoro e Nuova area di lavoro.
Assegnare all'area di lavoro il nome FoodSalesWS.
(Facoltativo) Aggiungere una descrizione.
Espandere la sezione Avanzate per visualizzare la modalità licenza.
Selezionare Versione di valutazione o Capacità Premium.
Selezionare Applica.
Per altre informazioni sulla creazione di un'area di lavoro, vedere Creare un'area di lavoro.
Passaggio 2: Caricare il contenuto nell'area di lavoro
È possibile caricare contenuto da OneDrive, SharePoint o da un file locale. In questa esercitazione viene caricato un file con estensione pbix .
Nella barra dei menu in alto selezionare Carica > sfoglia.
Passare al percorso del file FoodSales.pbixscaricato in precedenza oppure caricare il proprio modello semantico di esempio e il report.
È ora disponibile un'area di lavoro con contenuto per l'utente e il team su cui lavorare.
Modificare le credenziali: solo la prima volta
Prima di creare una pipeline di distribuzione, è necessario impostare le credenziali. Questo passaggio deve essere eseguito una sola volta per ogni modello semantico. Dopo aver impostato le credenziali per questo modello semantico, non sarà necessario impostarle di nuovo.
Vai a Impostazioni di Power BI>.
Selezionare Modelli semantici > Credenziali > origine dati Modifica credenziali.
Impostare Il metodo di autenticazione su Anonimo, il livello privacy su Pubblico e deselezionare la casella Ignora connessione di test .
Selezionare Accedi. La connessione viene testata e le credenziali vengono impostate.
Ora è possibile creare una pipeline di distribuzione.
Passaggio 3: Connettere l'area di lavoro di sviluppo del team a Git
L'intero team condivide questa area di lavoro e ogni membro del team può modificarla. Connettendo questa area di lavoro a Git, è possibile tenere traccia di tutte le modifiche e ripristinare le versioni precedenti, se necessario. Quando tutte le modifiche vengono unite in questo ramo condiviso, questa workspace verrà distribuita nell'ambiente di produzione usando la pipeline di deployment.
Altre informazioni sul controllo della versione con Git sono disponibili in Introduzione all'integrazione di Git.
Connettiamo questa area di lavoro al ramo principale del repository Git in modo tale che tutti i membri del team possano modificarla e creare richieste pull. Seguire questa procedura se si usa un repository di Azure DevOps. Se si usa un repository GitHub, seguire le istruzioni riportate in Connettere un'area di lavoro a un repository GitHub.
Passare alle impostazioni dell'area di lavoro nell'angolo in alto a destra.
Selezionare Integrazione Git.
Selezionare Azure DevOps. È stato effettuato l'accesso automatico all'account Azure Repos registrato all'utente Microsoft Entra connesso all'area di lavoro.
Dal menu a discesa specificare i dettagli seguenti sul ramo a cui ci si vuole connettere:
Selezionare il ramo principale (o master)
Digitare il nome della cartella nel repository in cui si trova il file con estensione pbix . Questa cartella verrà sincronizzata con l'area di lavoro.
Selezionare Connetti e sincronizza.
Dopo la connessione, l'area di lavoro visualizza informazioni sul controllo del codice sorgente che consente all'utente di visualizzare il ramo connesso, lo stato di ogni elemento nel ramo e l'ora dell'ultima sincronizzazione. L'icona del controllo del codice sorgente mostra 0
perché gli elementi nel repository dell'area di lavoro sono identici.
Ora l'area di lavoro è sincronizzata con il ramo principale del repository Git, rendendo più semplice tenere traccia delle modifiche.
Per altre informazioni sulla connessione a Git, vedere Connettere un'area di lavoro a un repository di Azure.
Passaggio 4: Creare una pipeline di distribuzione
Per condividere questa area di lavoro con altri utenti e usarla per varie fasi di test e sviluppo, è necessario creare una pipeline di distribuzione. Per informazioni sul funzionamento delle pipeline di distribuzione, vedere Introduzione alle pipeline di distribuzione. Per creare una pipeline di distribuzione e assegnare l'area di lavoro alla fase di sviluppo, seguire questa procedura:
Dall'home page dell'area di lavoro, selezionare Crea pipeline di distribuzione.
Assegnare alla pipeline il nome FoodSalesDP, assegnargli una descrizione (facoltativa) e selezionare Avanti.
Accettare le tre fasi predefinite per la pipeline e selezionare Crea.
Assegnare l'area di lavoro FoodSalesWS alla fase di sviluppo.
La fase di sviluppo della pipeline di distribuzione mostra un modello semantico, un report e un dashboard. Gli altri stadi sono vuoti.
Per altre informazioni sulla creazione di pipeline di distribuzione, vedere Panoramica delle pipeline di distribuzione.
Passaggio 5: Distribuire il contenuto in altre fasi
Ora, distribuisci il contenuto nelle altre fasi della pipeline.
Nella fase di sviluppo della visualizzazione del contenuto della distribuzione, selezionare Distribuisci.
Verificare di voler distribuire il contenuto nella fase di test.
L'icona di spunta verde indica che il contenuto delle due fasi è identico, poiché è stato distribuito l'intero contenuto della pipeline.
Distribuire il contenuto dalla fase di test alla fase di produzione.
Per aggiornare il modello semantico in qualsiasi fase, selezionare il pulsante Aggiorna accanto all'icona dei modelli semantici nella scheda di riepilogo di ogni fase.
Tutto il team condivide questa pipeline di distribuzione. Ogni membro del team può modificare il modello semantico e il report nella fase di sviluppo. Quando il team è pronto per testare le modifiche, distribuisce il contenuto nella fase di test. Quando il team è pronto a rilasciare le modifiche apportate all'ambiente di produzione, distribuisce il contenuto nella fase di produzione.
Per altre informazioni sulla distribuzione del contenuto, vedere Distribuire il contenuto.
Passaggio 6: Creare un'area di lavoro isolata
Per evitare di modificare l'area di lavoro condivisa e interferire con le modifiche degli altri membri del team, ogni membro del team deve creare una propria area di lavoro isolata in cui lavorare fino a quando non è pronto a condividere le modifiche con il team.
Nella scheda Ramo del menu Controllo del codice sorgente, selezionare la freccia giù accanto al nome del ramo corrente e selezionare Dirama in un nuovo spazio di lavoro.
Specificare i dettagli seguenti relativi al ramo e all'area di lavoro. Il nuovo ramo viene creato automaticamente in base al ramo connesso all'area di lavoro corrente.
- Nome ramo (per questa esercitazione, denominarlo MyFoodEdits)
- Nome dell'area di lavoro (per questa esercitazione denominarlo My_FoodSales)
Selezionare Diramazione.
Selezionare Connetti e sincronizza.
Fabric crea la nuova area di lavoro e la sincronizza con il nuovo ramo. Si arriva automaticamente alla nuova area di lavoro, ma la sincronizzazione potrebbe richiedere alcuni minuti.
La nuova area di lavoro include ora il contenuto della cartella repository Git. Si noti che non contiene il file con estensione pbix . Poiché i file con estensione pbix non sono supportati, questo file non è stato copiato nel repository Git durante la sincronizzazione.
Usare questa area di lavoro per apportare modifiche al modello semantico e al report finché non si è pronti per condividerli con il team.
Passaggio 7: Modificare l'area di lavoro
Dopo aver sincronizzato l'area di lavoro ramificata, è possibile apportare modifiche all'area di lavoro creando, eliminando o modificando un elemento. In questa esercitazione, viene modificato il formato di una colonna del modello semantico. È possibile modificare l'area di lavoro in Power BI Desktop o nel modello di dati. In questa esercitazione, si modifica l'area di lavoro dal modello di dati.
Nell'area di lavoro del modello semantico, selezionare i puntini di sospensione (tre punti) del modello semantico e >apri il modello di dati.
Nota
Se Open data model è disabilitato, passare a Impostazioni > area di lavoro Power BI > Generale e abilitare le impostazioni del modello di dati.
Nella tabella Order_details selezionare Sconto.
Nel riquadro Proprietà modificare il formato da Generale a Percentuale.
Screenshot della pubblicazione delle modifiche in Git.
Passaggio 8: Confermare le modifiche
Per eseguire il commit di questa modifica dall'area di lavoro al ramo Git, tornare alla pagina iniziale dell'area di lavoro.
L'icona del controllo del codice sorgente mostra ora 1
perché un elemento nell'area di lavoro è stato modificato ma non è stato eseguito il commit nel repository Git. Il modello semantico FoodSales mostra lo stato Uncommitted.
Selezionare l'icona del controllo del codice sorgente per visualizzare gli elementi modificati nel repository Git. Il modello semantico mostra lo stato Modificato.
Selezionare l'elemento per eseguire il commit e aggiungere un messaggio facoltativo.
Selezionare Commit.
Lo stato Git del modello semantico cambia in Sincronizzato e l'area di lavoro e il repository Git sono sincronizzati.
Passaggio 9: Creare una pull request e fondere
Nel repository Git creare una richiesta pull per unire il ramo MyFoodEdits al ramo main .
Questo passaggio può essere eseguito manualmente o automatizzato:
Selezionare Crea una richiesta pull.
Specificare un titolo, una descrizione e altre informazioni desiderate per la richiesta pull. Selezionare quindi Crea.
-
Dopo aver unito le modifiche al ramo principale, si può eliminare in modo sicuro l'area di lavoro, se necessario. Non viene eliminata automaticamente.
Passaggio 10: Aggiornare l'area di lavoro condivisa
Tornare all'area di lavoro condivisa connessa alla fase di sviluppo della pipeline di distribuzione (quella creata nel passaggio 1) e aggiornare la pagina.
L'icona del controllo del codice sorgente mostra ora 1 perché un elemento nel repository Git è stato modificato ed è diverso dagli elementi nell'area di lavoro FoodSales. Il modello semantico FoodSales mostra lo stato Update obbligatorio.
È possibile aggiornare l'area di lavoro manualmente o automatizzata:
Selezionare l'icona del controllo del codice sorgente per visualizzare gli elementi modificati nel repository Git. Il modello semantico mostra lo stato Modificato.
Selezionare Aggiorna tutto.
Lo stato Git del modello semantico cambia in Sincronizzato e l'area di lavoro viene sincronizzata con il ramo Git principale .
Passaggio 11: Confrontare le fasi nella pipeline di distribuzione
Selezionare Visualizza pipeline di distribuzione per confrontare il contenuto nella fase di sviluppo con il contenuto nella fase di test.
Si noti l'icona
X
arancione tra le fasi che indica che sono state apportate modifiche al contenuto in una delle fasi successive all'ultima distribuzione.Selezionare la freccia > giù Rivedi modifiche per visualizzare le modifiche. La schermata Modifica revisione mostra la differenza tra i modelli semantici nelle due fasi.
Rivedere le modifiche e chiudere la finestra.
Per altre informazioni sul confronto delle fasi in una pipeline di distribuzione, vedere Confrontare le fasi in una pipeline di distribuzione.
Passaggio 12: Distribuire nella fase di test
Quando si è soddisfatti delle modifiche, distribuire le modifiche alle fasi di test e/o produzione usando lo stesso processo usato nel passaggio 5.
Riepilogo
Questa esercitazione ha illustrato come usare le pipeline di distribuzione insieme all'integrazione Git per gestire il ciclo di vita di un'app, di un report o di altro contenuto in un'area di lavoro.
In particolare, si è appreso come:
- Configurare le aree di lavoro e aggiungere contenuto per la gestione del ciclo di vita in Fabric.
- Applicare le procedure consigliate di Git per lavorare da soli e collaborare con i colleghi sulle modifiche.
- Combinare Git e pipeline di distribuzione per un processo di rilascio completo ed efficiente.