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 discussione della parte di 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 il tessuto

Per accedere alla funzionalità di integrazione Git, è necessaria una Fabric capacity. È necessaria una capacità di Fabric per utilizzare tutti gli elementi supportati da Fabric. Se non si ha ancora una sottoscrizione, iscriversi per ottenere una versione di valutazione gratuita. I clienti che hanno già una capacità Power BI Premiumpossono usare tale capacità, ma bisogna tenere presente che determinati SKU di Power BI supportano solo gli elementi Power BI.

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
• Creare aree di lavoro (solo se si vuole espandere verso 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 di capacità o dall'amministratore dell'area di lavoro, a seconda delle impostazioni dell'organizzazione.

I prerequisiti di 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:

Processo di sviluppo

L'area di lavoro Fabric è un ambiente condiviso che consente di accedere agli elementi live. Eventuali modifiche apportate direttamente nell'area di lavoro sovrascrivono e influenzano 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.

• Sviluppa utilizzando strumenti client, come 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 necessariamente all'interno di 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 in un 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 a più dati. Per testare le modifiche, connettere il nuovo ramo a un'area di lavoro separata e caricare il modello semantico e i report usando il aggiornare tutti i pulsante 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 Branches del menu controllo del codice sorgente, selezionare Diramare in un'altra area di lavoro.

   

2. Specificare se si vuole creare una nuova area di lavoro o passare a una nuova area di lavoro esistente. Specificare i nomi del nuovo ramo e dell'area di lavoro oppure selezionare l'area di lavoro esistente dall'elenco a discesa. Quando si esegue la diramazione in un'area di lavoro, tutti gli elementi che non vengono salvati in Git possono andare persi. È consigliabile eseguire il commit di tutti gli elementi che si desidera mantenere prima della diramazione.

   

3. Seleziona Branch out.

   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 sull'espandersi, vedere i suggerimenti per la risoluzione dei problemi.

   

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

5. Quando si è pronti, creare una pull request sul 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 ulteriori informazioni, vedere limitazioni di diramazione.

Processo di rilascio

Il processo di rilascio inizia una volta completato un Pull Request e il merge nel ramo condiviso del team, ad esempio Main, Deve così via. Da questo punto sono disponibili diverse opzioni per compilare un processo di rilascio in Fabric. Per informazioni sulle diverse opzioni da considerare durante la progettazione del flusso di lavoro, vedere processo di rilascio.

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 di controllo del codice sorgente, selezionare Passa al 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 ramificazioni se sono presenti modifiche non salvate 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