Gestire i rami nelle aree di lavoro di Microsoft Fabric

L'obiettivo di questo articolo è presentare agli sviluppatori di Fabric diverse opzioni per la creazione di processi CI/CD in Fabric, in base agli scenari dei clienti comuni. Questo articolo è incentrato maggiormente sulla parte di integrazione continua (CI) del processo CI/CD. Per una descrizione della parte recapito continuo (CD), vedere Gestire le pipeline di distribuzione.

Questo articolo illustra alcune opzioni di integrazione distinte, ma molte organizzazioni usano una combinazione di esse.

Prerequisiti

Per integrare Git con l'area di lavoro di Microsoft Fabric, è necessario configurare i prerequisiti seguenti per Fabric e Git.

Prerequisiti per l'infrastruttura

Per accedere alla funzionalità di integrazione Git, è necessario uno dei seguenti:

• Licenza di Power BI Premium. Una licenza di Power BI Premium supporta solo tutti gli elementi di Power BI.
• Capacità dell'infrastruttura. Per usare tutti gli elementi Fabric supportati, è necessaria una capacità infrastruttura. Se non si ha ancora una sottoscrizione, iscriversi per ottenere una versione di valutazione gratuita.

Inoltre, le seguenti opzioni del tenant devono essere abilitate dal portale di amministrazione:

• Gli utenti possono creare elementi Fabric
• Gli utenti possono sincronizzare gli elementi dell'area di lavoro con i propri repository Git
• Solo per gli utenti GitHub: gli utenti possono sincronizzare gli elementi dell'area di lavoro con i repository GitHub

Queste opzioni possono essere abilitate dall'amministratore tenant, dall'amministratore di 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:

Azure DevOps

• Un account Azure attivo registrato con lo stesso utente che usa l'area di lavoro Infrastruttura. Creare un account gratuito.
• Accesso a un repository esistente.

GitHub

• Un account GitHub attivo. Creare un account GitHub.

• Uno dei seguenti token di accesso personale:

  • Un token con granularità fine, che rappresenta la scelta consigliata, con autorizzazione di lettura e scrittura del Contenuto nelle autorizzazioni del repository:

    

    Per usare questo token con GitHub Enterprise, seguire queste istruzioni.

  • Creare un token GitHub classico con ambiti di repository abilitati:

    

Processo di sviluppo

L'area di lavoro Fabric è un ambiente condiviso che permette l'accesso agli elementi live. Eventuali modifiche apportate direttamente nell'area di lavoro sostituiscono e vengono applicati anche a tutti gli altri utenti dell'area di lavoro. Pertanto, la procedura consigliata di Git è che gli sviluppatori funzionino in isolamento all'esterno delle aree di lavoro condivise. Esistono due modi per consentire a uno sviluppatore di lavorare nella propria area di lavoro protetta.

• Eseguire le attività usando strumenti client, quali Power BI Desktop per report e modelli semantici o VS Code per Notebook.
• Eseguire le attività in un'area di lavoro Fabric separata. Ogni sviluppatore ha una propria area di lavoro in cui collega il proprio ramo separato, sincronizza il contenuto in tale area di lavoro e quindi esegue il commit nuovamente nel ramo.

Per lavorare con i rami usando l'integrazione Git, collegare prima di tutto l'area di lavoro del team di sviluppo condiviso a un singolo ramo condiviso. Per esempio, se il team usa un'area di lavoro condivisa, collegarla al ramo principale nel repository del team ed eseguire la sincronizzazione tra area di lavoro e repository. Se il flusso di lavoro del team ha molteplici rami condivisi, quali rami Sviluppo/Test/Prod, ciascun ramo può essere collegato a un'area di lavoro differente.

Pertanto, ogni sviluppatore può scegliere l'ambiente isolato in cui lavorare.

Scenario 1 - Sviluppare usando gli strumenti client

Se gli elementi in fase di sviluppo sono disponibili in altri strumenti, è possibile lavorare su tali elementi direttamente nello strumento client. Non tutti gli elementi sono disponibili in ogni strumento. Gli elementi disponibili solo in Fabric devono essere sviluppati in Fabric.

Il flusso di lavoro per gli sviluppatori che usano uno strumento client come Power BI Desktop dovrebbe essere simile a quanto segue:

1. Clonare il repository nel computer locale. Questa operazione sarà eseguita una sola volta.

2. Aprire il progetto in Power BI Desktop usando la copia locale di PBIProj.

3. Apportare modifiche e salvare localmente i file aggiornati. Eseguire il commit nel repository locale.

4. Quando si è pronti, inviare il ramo ed eseguire il commit nel repository remoto.

5. Testare le modifiche rispetto ad altri elementi o più dati collegando il nuovo ramo a un'area di lavoro separata e caricando il modello semantico e i report usando il pulsante Aggiorna tutto nel pannello di controllo del codice sorgente. Eseguire ora eventuali test o apportare modifiche alla configurazione, prima di eseguire l'unione nel ramo principale.

   Se nell'area di lavoro non è necessario alcun test, lo sviluppatore può unire le modifiche direttamente nel ramo principale, senza la necessità di un'altra area di lavoro.

6. Una volta unite le modifiche, all'area di lavoro del team condiviso viene richiesto di accettare il nuovo commit. Le modifiche vengono aggiornate nell'area di lavoro condivisa e tutti possono visualizzare le modifiche apportate a tali modelli semantici e report.

Per indicazioni specifiche su come usare il nuovo formato di file Power BI Desktop in Git, vedere Formato del codice sorgente.

Scenario 2 - Sviluppare usando un'altra area di lavoro

Per uno sviluppatore che lavora nel Web, il flusso sarà il seguente:

1. Nella scheda Rami del menu Controllo del codice sorgente, selezionare Ramificare in nuova area di lavoro.

   

2. Specificare i nomi del ramo e dell'area di lavoro. Nuovo ramo creato in base al ramo collegato all'area di lavoro corrente.

   

3. Selezionare Ramificare.

   Fabric crea l'area di lavoro e il ramo nuovi. Viene visualizzata automaticamente la nuova area di lavoro.

   L'area di lavoro viene sincronizzata con il ramo di funzionalità e diventa un ambiente isolato in cui lavorare, come illustrato. Ora, è possibile lavorare in questo nuovo ambiente isolato. La sincronizzazione potrebbe richiedere alcuni minuti. Per ulteriori informazioni sulla ramificazione, vedere i consigli per la risoluzione dei problemi.

   

4. Salvare le modifiche ed eseguirne il commit nel ramo di funzionalità.

5. Quando si è pronti, creare una richiesta pull al ramo principale. I processi di revisione e di unione vengono eseguiti tramite Azure Repos, in base alla configurazione definita dal team per tale repository.

Una volta completata la revisione e l'unione, viene creato un nuovo commit nel ramo principale. Questo commit richiede all'utente di aggiornare il contenuto nell'area di lavoro del team di sviluppo con le modifiche unite.

Per altre informazioni, vedere ‬Limitazioni dei rami‭.

Processo di rilascio

Il processo di rilascio inizia una volta che i nuovi aggiornamenti completano un processo di richiesta pull e si uniscono nel ramo condiviso del team (ad esempio Main, Dev e così via). Da questo punto verranno illustrate le diverse opzioni per compilare un processo di rilascio in Fabric. È possibile trovare le diverse considerazioni per il processo di rilascio nella gestione delle pipeline di distribuzione.

Cambiare ramo

Se l'area di lavoro è connessa a un ramo Git e si vuole passare a un altro ramo, è possibile farlo rapidamente dal riquadro Controllo del codice sorgente senza disconnettersi e riconnettersi.
Quando si cambia ramo, l'area di lavoro viene sincronizzata con il nuovo ramo e tutti gli elementi nell'area di lavoro vengono sostituiti. Se in ciascun ramo sono presenti versioni diverse dello stesso elemento, l'elemento viene sostituito. Se un elemento si trova nel ramo vecchio, ma non in quello nuovo, viene eliminato. Per passare da un ramo all'altro, seguire questa procedura:

1. Nella scheda Rami del menu Controllo del codice sorgente selezionare Cambia ramo.

   

2. Specificare il ramo a cui connettersi o creare un nuovo ramo. Questo ramo deve contenere la stessa directory del ramo corrente.

3. Selezionare Cambia ramo.

Non è possibile cambiare rami se sono presenti modifiche di cui non è stato eseguito il commit nell'area di lavoro. Selezionare Annulla per tornare indietro ed eseguire il commit delle modifiche prima di passare dai rami.

Per connettere l'area di lavoro corrente a un nuovo ramo mantenendo lo stato dell'area di lavoro esistente, selezionare Checkout new branch (Estrai nuovo ramo). Altre informazioni sul controllo di un nuovo ramo sono disponibili in Risolvere i conflitti in Git.

Contenuto correlato

• Risolvere errori e conflitti
• Procedure consigliate per l'integrazione di Git