Che cos'è l'integrazione git di Microsoft Fabric?
Questo articolo illustra agli sviluppatori come integrare il controllo della versione di Git con lo strumento di gestione del ciclo di vita delle applicazioni di Microsoft Fabric.
Nota
Alcuni elementi per l'integrazione git sono disponibili in anteprima. Per altre informazioni, vedere l'elenco degli elementi supportati.
L'integrazione con Git in Microsoft Fabric consente di integrare processi di sviluppo, strumenti e procedure consigliate direttamente nella piattaforma Fabric. Consente agli sviluppatori che sviluppano in Fabric di:
- Fare il backup e versionare il lavoro
- Ripristinare le fasi precedenti in base alle esigenze
- Collaborare con altri utenti o lavorare da soli usando i rami Git
- Applicare le capacità degli strumenti di controllo del codice sorgente familiari per gestire gli elementi di Fabric
Consulta l'elenco degli elementi supportati .
Approfondisci i concetti di base di Git e controllo di versione .
Altre informazioni sul processo di integrazione Git.
Informazioni sul modo migliore per gestire i rami Git.
Informazioni sulla privacy
Prima di abilitare l'integrazione di Git, assicurarsi di esaminare le seguenti informative sulla privacy:
- Informativa sulla privacy di Microsoft
- Panoramica della protezione dei dati personali di Azure DevOps Services
- Contratto di protezione dei dati personali di GitHub
Fornitori Git supportati
Sono supportati i provider Git seguenti:
- Git in Azure Repos con lo stesso tenant di Fabric
- GitHub (solo versioni cloud)
- GitHub Enterprise (solo versioni cloud)
Elementi supportati
Sono attualmente supportati gli elementi seguenti:
- Pipeline didati (anteprima)
- Flussi di dati gen2(anteprima)
- Eventhouse e il database KQL(anteprima)
- EventStream(anteprima)
- Lakehouse(anteprima)
- Database speculare(anteprima)
- Notebooks
- Report impaginati(anteprima)
- Riflesso (anteprima)
- report (ad eccezione dei report connessi a modelli semantici ospitati in Azure Analysis Services, SQL Server Analysis Serviceso report esportati da Power BI Desktop che dipendono da modelli semantici ospitati in MyWorkspace) (anteprima)
- Modelli semantici (ad eccezione dei set di dati push, connessioni dinamiche ad Analysis Services, modello v1) (anteprima)
- Definizioni di processi di lavoro Spark(anteprima)
- Ambiente Spark (anteprima)
- Database SQL(anteprima)
- Magazzini (anteprima)
Se l'area di lavoro o la directory Git non include elementi non supportati, è comunque possibile connettersi, ma gli elementi non supportati vengono ignorati. Non vengono salvati o sincronizzati, ma non vengono eliminati. Appaiono nel pannello di controllo del codice sorgente, ma non è possibile eseguirne il commit o l'aggiornamento.
Considerazioni e limitazioni
Limitazioni generali per l'integrazione di Git
- Il metodo di autenticazione in Fabric deve essere almeno sicuro quanto il metodo di autenticazione per Git. Ad esempio, se Git richiede l'autenticazione a più fattori, anche Fabric deve richiedere l'autenticazione a più fattori.
- I set di dati di Power BI connessi ad Analysis Services non sono attualmente supportati.
- Le aree di lavoro con app modello installate non possono essere connesse a Git.
- I moduli secondari non sono supportati.
- Il cloud sovrano non è supportato.
- L'account Azure DevOps deve essere registrato allo stesso utente che usa l'area di lavoro di Fabric.
- Azure DevOps non è supportato se è abilitata la convalida del criterio di accesso condizionale IP.
- L'amministratore tenant deve abilitare le esportazioni tra aree geografiche se l'area di lavoro e il repository Git si trovano in due aree geografiche diverse.
- Se l'organizzazione ha configurato l'accesso condizionale, assicurarsi che l'del servizio Power BI abbia le stesse condizioni di impostate affinché l'autenticazione funzioni come previsto.
- La dimensione del commit è limitata a 125 MB.
Limitazioni di GitHub Enterprise
Alcune impostazioni di GitHub Enterprise non sono supportate. Ad esempio:
- Elenco IP consentiti
- Networking privato
- Domini personalizzati
Limitazioni dell'area di lavoro
- Solo l'amministratore dell'area di lavoro può gestire le connessioni al repository Git, come la connessione, la disconnessione o l'aggiunta di un ramo.
Dopo la connessione, chiunque disponga dell'autorizzazione può lavorare nell'area di lavoro.
Limitazioni dei rami e delle cartelle
- La lunghezza massima del nome del ramo è di 244 caratteri.
- La lunghezza massima del percorso completo per i nomi dei file è di 250 caratteri. I nomi troppo lunghi falliscono.
- La dimensione massima del file è di 25 MB.
- La struttura delle cartelle viene mantenuta fino a 10 livelli di profondità.
- Non è possibile scaricare un report o un set di dati in formato .pbix dal servizio dopo la distribuzione con l'integrazione git.
- Se il nome visualizzato dell'elemento presenta una di queste caratteristiche, la cartella Git viene rinominata con l'ID logico (Guid) e il tipo:
- Quando si connette un'area di lavoro con cartelle a Git, è necessario eseguire il commit delle modifiche al repository Git se tale struttura di cartelle è diversa.
Limitazioni dei nomi delle directory
Il nome della directory che si connette al repository Git presenta le restrizioni di denominazione seguenti:
- Il nome della directory non può iniziare o terminare con uno spazio o una scheda.
- Il nome della directory non può contenere i caratteri seguenti: "/:<>\*?|
La cartella dell'elemento (la cartella contenente i file di elemento) non può contenere i caratteri seguenti: ":<>\*?|. Se si rinomina la cartella in un elemento che include uno di questi caratteri, Git non può connettersi o sincronizzare con l'area di lavoro e si verifica un errore.
Limiti dell'espansione
- Branch out richiede le autorizzazioni elencate nella tabella delle autorizzazioni.
- Per questa azione deve esserci una capacità disponibile.
- Tutte le limitazioni di denominazione dei rami e dell'area di lavoro si applicano quando si esegue la diramazione in una nuova area di lavoro.
- Nella nuova area di lavoro sono disponibili solo gli elementi supportati da Git.
- L'elenco dei rami correlati mostra solo rami e aree di lavoro per cui si dispone dell'autorizzazione per la visualizzazione.
- L'integrazione Git deve essere abilitata.
- Quando si esegue la diramazione, viene creato un nuovo ramo e le impostazioni del ramo originale non vengono copiate. Modificare le impostazioni o le definizioni per assicurarsi che il nuovo soddisfi i criteri dell'organizzazione.
- Quando si esegue la diramazione in un'area di lavoro esistente:
- L'area di lavoro di destinazione deve supportare una connessione Git.
- L'utente deve essere un amministratore dell'area di lavoro di destinazione.
- L'area di lavoro di destinazione deve avere capacità.
- L'area di lavoro non può avere applicazioni modello.
- Si noti che quando si passa a un'area di lavoro, eventuali elementi che non vengono salvati in Git possono essere persi. È consigliabile effettuare il commit di tutti gli elementi che vuoi mantenere prima di creare un branch.
Limitazioni di sincronizzazione e commit
- È possibile eseguire la sincronizzazione in una sola direzione alla volta. Non è possibile eseguire il commit e l'aggiornamento contemporaneamente.
- Le etichette di riservatezza non sono supportate e l'esportazione di elementi con etichette di riservatezza potrebbe essere disabilitata. Per confermare elementi etichettati come riservati senza l'etichetta di riservatezza, chiedere assistenza all'amministratore.
- Funziona con elementi limitati. Gli elementi non supportati nella cartella vengono ignorati.
- La duplicazione dei nomi non è consentita. Anche se Power BI consente la duplicazione dei nomi, l'azione di aggiornamento, commit o annullamento ha esito negativo.
- B2B non è supportato.
- La risoluzione del conflitto viene eseguita parzialmente in Git.
- Durante il processo Commit in Git, il servizio di Fabric elimina i file all'interno della cartella dell'elemento che non fanno parte della definizione dell'elemento. I file non correlati non presenti in una cartella di elementi non vengono eliminati.
- Dopo aver salvato le modifiche, potresti notare alcune modifiche impreviste all'elemento che non hai effettuato. Queste modifiche sono semanticamente insignificanti e possono verificarsi per diversi motivi. Ad esempio:
- Modificare manualmente il file di definizione dell'elemento. Queste modifiche sono valide, ma potrebbero essere diverse da quelle eseguite tramite gli editor. Ad esempio, se si rinomina una colonna del modello semantico in Git e si importa questa modifica nell'area di lavoro, al successivo commit delle modifiche apportate al modello semantico, il file bim verrà registrato come modificato e la colonna modificata verrà riportata alla fine della matrice
columns
. Questo perché il motore AS che genera i file bim sposta le colonne rinominate alla fine della matrice. Questa modifica non influisce sul funzionamento dell'elemento. - Eseguire il commit di un file che utilizza interruzioni di riga CRLF. Il servizio utilizza LF (line feed - avanzamento riga) per interrompere le righe. Se nel repository Git fossero presenti file di elementi con interruzioni di riga CRLF, quando si esegue il commit dal servizio questi file verrebbero modificati in LF. Ad esempio, se si apre un report sul desktop, salvare il file di progetto (pbip ) e caricarlo in Git usando CRLF.
- Modificare manualmente il file di definizione dell'elemento. Queste modifiche sono valide, ma potrebbero essere diverse da quelle eseguite tramite gli editor. Ad esempio, se si rinomina una colonna del modello semantico in Git e si importa questa modifica nell'area di lavoro, al successivo commit delle modifiche apportate al modello semantico, il file bim verrà registrato come modificato e la colonna modificata verrà riportata alla fine della matrice
- L'aggiornamento di un modello semantico tramite l'API Aggiornamento avanzato causa una differenza di Git dopo ogni aggiornamento.