Condividi tramite


Pipeline di compilazione di Power BI Project (PBIP) e Azure DevOps per la convalida

Combinando l'integrazione git di Fabric con Azure DevOps, è possibile connettere un'area di lavoro a un ramo in un repository Azure DevOps e sincronizzarle automaticamente tra di esse.

L'integrazione del formato PBIP con Azure DevOps consente di usare Azure Pipelines per automatizzare le pipeline di integrazione continua/distribuzione continua (CI/CD). Queste pipeline elaborano i file di metadati PBIP e applicano una serie di controlli di qualità allo sviluppo prima di distribuirli nel sistema di produzione.

In questo articolo viene illustrato l'integrazione continua e viene descritto come creare una pipeline di Azure DevOps che garantisce le procedure consigliate per tutti i modelli semantici e i report all'interno di un'area di lavoro infrastruttura. Implementando test di qualità automatizzati, è possibile prevenire errori comuni e migliorare l'efficienza del team. Ad esempio, questo approccio garantisce che i nuovi membri del team rispettino gli standard stabiliti per lo sviluppo di modelli semantici e report.

Altre informazioni sull'integrazione git di PBIP e Fabric sono disponibili in panoramica del progetto e panoramica dell'integrazione git di Fabric.

Il diagramma seguente illustra lo scenario end-to-end con due flussi di lavoro di sviluppo che attivano la pipeline di Azure DevOps per convalidare la qualità dello sviluppo. L'esecuzione della pipeline esegue le azioni seguenti:

Diagramma che mostra il flusso di lavoro della pipeline DevOps.

  1. L'utente 1 sviluppa usando Power BI Desktop.

    1. Creare un ramo da main usando VS Code (funzionalità/modifica del set di dati)
    2. Apportare modifiche al modello semantico con Power BI Desktop
    3. Eseguire il commit delle modifiche nel ramo del repository remoto usando VS Code
    4. Creare una richiesta pull al ramo principale usando Azure DevOps
  2. Allo stesso tempo, l'utente 2 sviluppa l'uso di un'altra area di lavoro fabric.

    1. Creare un ramo da main usando Fabric Git (funzionalità/reportchange)
    2. Apportare modifiche ai report nell'area di lavoro Infrastruttura
    3. Eseguire il commit delle modifiche nel ramo del repository remoto usando Git di Fabric
    4. Creare una richiesta pull al ramo principale usando Azure DevOps
  3. Il responsabile del team esamina le richieste pull e sincronizza le modifiche all'area di lavoro del team usando Fabric Git.

  4. La richiesta pull attiva la pipeline di Azure DevOps per esaminare il modello semantico e la qualità dello sviluppo dei report.

Nota

In questo esempio, la pipeline usa due strumenti della community open source che consentono a uno sviluppatore di applicare (personalizzabili) regole consigliate ai metadati dei modelli semantici e dei report all'interno di una cartella del progetto di Power BI:

Un approccio simile all'esempio riportato in questo articolo si applica ad altri strumenti della community. Questo articolo non illustra le specifiche degli strumenti della community menzionati in precedenza, né la creazione e la modifica di regole. Per informazioni approfondite su questi argomenti, vedere i collegamenti forniti. L'obiettivo di questo articolo è il processo di definizione di un controllo di qualità tra il controllo del codice sorgente e l'area di lavoro infrastruttura. È importante notare che gli strumenti della community di riferimento sono sviluppati da collaboratori di terze parti e Microsoft non offre supporto o documentazione per tali utenti.

Passaggio 1: Connettere l'area di lavoro infrastruttura ad Azure DevOps

Connettere l'area di lavoro infrastruttura ad Azure DevOps:

Screenshot che mostra la connessione Git a DevOps.

Al termine dell'esportazione degli elementi dell'area di lavoro, il ramo Azure DevOps conterrà una cartella per ogni elemento nell'area di lavoro:

Screenshot che mostra il ramo Azure DevOps con cartelle per diversi elementi dell'area di lavoro.

Passaggio 2: Creare ed eseguire una pipeline di Azure DevOps

Per creare una nuova pipeline:

  1. Nella scheda Pipeline del menu di spostamento a sinistra selezionare Crea pipeline:

    Screenshot che mostra come creare una pipeline.

  2. Selezionare Azure Repos Git e selezionare il primo repository (lo stesso repository connesso all'area di lavoro Infrastruttura):

    Screenshot che mostra l'opzione Git del repository di Azure selezionata come origine del codice per la pipeline.

    Screenshot che mostra il repository Demo-ADObuild selezionato.

  3. Selezionare Pipeline starter.

    Screenshot che mostra l'icona della pipeline di avvio selezionata.

    Nell'editor viene visualizzato il codice YAML seguente:

    Screenshot che mostra il codice YAML predefinito.

  4. Copiare e incollare il codice YAML dalla pipeline in modalità sviluppatore di Power BI nella pipeline creata:

    Screenshot che mostra il codice YAML da aggiungere.

    Screenshot che mostra la seconda parte del codice YAML.

  5. Selezionare Salva ed esegui per eseguire il commit della nuova pipeline nel repository.

    Screenshot di una revisione del codice YAML.

    Screenshot che mostra la selezione di salvataggio ed esecuzione.

Azure DevOps esegue la pipeline e avvia due processi di compilazione in parallelo:

Screenshot che mostra Azure DevOps che esegue una pipeline.

  • Build_Datasets
    • Scarica i file binari dell'editor tabulare.
    • Scaricare le regole predefinite di Best Practice Analyzer. Per personalizzare le regole, aggiungere un Rules-Dataset.json alla radice del repository.
    • Scorrere tutte le cartelle degli elementi del modello semantico ed eseguire regole BPA dell'editor tabulare.
  • Build_Reports
    • Scaricare i file binari di PBI Inspector.
    • Scaricare le regole predefinite di Controllo PBI. Per personalizzare le regole, aggiungere un Rules-Report.json alla radice del repository.
    • Scorrere tutte le cartelle degli elementi del report ed eseguire le regole di controllo di Power BI.

Al termine, Azure DevOps crea un report di tutti gli avvisi e gli errori rilevati:

Screenshot che mostra la segnalazione degli errori.

Selezionare il collegamento per aprire una visualizzazione più dettagliata dei due processi:

Screenshot che mostra il pulsante Visualizza log.

Screenshot che mostra il log degli errori espanso.

Se il report o il modello semantico non riesce una regola con un livello di gravità superiore, la compilazione ha esito negativo e l'errore è evidenziato:

Screenshot che mostra gli errori dell'evidenziatore.

Passaggio 3- Definire i criteri dei rami

Quando la pipeline è attiva e in esecuzione, abilitare Criteri di ramo nel ramo main . Questo passaggio garantisce che non sia possibile eseguire alcun commit direttamente in main. Una "richiesta pull" è sempre necessaria per unire nuovamente le modifiche in main ed è possibile configurare la pipeline per l'esecuzione con ogni richiesta pull.

  1. Selezionare Rami principali Branch Branch>policies (Rami>principali):

    Screenshot che mostra i criteri dei rami.

  2. Configurare la pipeline creata come criteri di compilazione per il ramo:

    Screenshot che mostra l'interfaccia utente dei criteri di compilazione.

    Screenshot che mostra la seconda parte dell'interfaccia utente dei criteri di compilazione.

Passaggio 4: Creare una richiesta pull

Se si torna all'area di lavoro infrastruttura, apportare una modifica a uno dei report o ai modelli semantici e tentare di eseguire il commit della modifica, viene visualizzato l'errore seguente:

Screenshot che mostra l'errore non è possibile eseguire il commit della modifica.

È possibile apportare modifiche al ramo main solo tramite una richiesta pull. Per creare una richiesta pull estrae un nuovo ramo per apportare le modifiche:

Creare un ramo direttamente dall'area di lavoro infrastruttura:

  1. Nel riquadro Controllo del codice sorgente selezionare Checkout new branch (Estrazione nuovo ramo ) e specificare un nome per il ramo.

    Screenshot che mostra la schermata del controllo del codice sorgente per estrarre un nuovo ramo.

    Screenshot che mostra come estrarre un nuovo ramo.

    In alternativa, è possibile scegliere di sviluppare in un'area di lavoro separata isolata o in Power BI Desktop. Per altre informazioni, vedere Sviluppare usando un'altra area di lavoro

  2. Eseguire il commit delle modifiche in questo nuovo ramo.

    Screenshot che mostra le modifiche di commit nel ramo.

  3. Dopo il commit, creare una richiesta pull nel ramo principale dal portale di Azure DevOps.

    Screenshot che mostra una nuova richiesta pull creata.

    Screenshot che mostra la richiesta pull creata.

Il flusso di lavoro della richiesta pull non solo consente di convalidare ed esaminare le modifiche, ma anche di attivare automaticamente la pipeline.

Screenshot che mostra la modifica del report.

Se si verifica un errore di gravità elevata in una delle regole, non è possibile finalizzare la richiesta pull e unire nuovamente le modifiche nel ramo principale.

Screenshot della richiesta pull completata.

Altre informazioni sull'integrazione git di PBIP e Fabric sono disponibili nel post di blog.