Dashboard di controllo della versione con Git

Questa pagina illustra come usare le cartelle Git di Databricks per il controllo della versione e lo sviluppo di dashboard collaborativi. Descrive anche come implementare processi CI/CD per sviluppare e distribuire dashboard in aree di lavoro diverse.

Importante

Questa funzionalità è in Anteprima Pubblica.

Panoramica

Le cartelle Git di Databricks tengono traccia delle modifiche e della cronologia del dashboard, della collaborazione del team di supporto e consentono di distribuire i dashboard nell'ambiente di produzione e ripristinare le versioni precedenti.

Abilitare il controllo del codice sorgente del dashboard

Gli amministratori dell'area di lavoro possono controllare l'accesso dell'area di lavoro all'anteprima pubblica dalla pagina Anteprime. Per impostazione predefinita, l'anteprima dei dashboard di supporto nella cartella Git è Attivata.

Funzionamento dell'integrazione di Git con i dashboard

Le cartelle Git di Databricks tengono traccia e gestiscono le modifiche apportate ai dashboard bozza . La bozza di dashboard riflette tutte le modifiche in un dashboard monitorato. Git non tiene traccia delle configurazioni di pubblicazione e pianificazione, ad esempio la selezione del magazzino e la creazione della pianificazione. Per gestire queste configurazioni, usare l'interfaccia utente o automatizzare le modifiche con i bundle di asset di Databricks o l'API REST di intelligenza artificiale/BI.

• Per usare i bundle per la gestione dei dashboard, vedere dashboard.
• Per pubblicare e pianificare i dashboard con l'API REST, vedere le informazioni di riferimento sull'API Lakeview .

Annotazioni

L'API Lakeview usa il nome precedente per i dashboard di intelligenza artificiale/BI.

Le cartelle Git di Databricks gestiscono operazioni Git comuni per dashboard e altri oggetti dell'area di lavoro. Per altre informazioni, vedere Cartelle Git di Azure Databricks.

Applicazione del controllo del codice sorgente ai dashboard

Per tenere traccia dei dashboard con Git, inserirli in una cartella Git di Databricks. Usare una delle opzioni seguenti:

• Nuovi dashboard: Creare il dashboard all'interno di una cartella Git databricks esistente per applicare il controllo del codice sorgente dall'inizio.
• Dashboard esistenti: Spostare un dashboard esistente in una cartella Git di Databricks per tenerne traccia con Git.

Gestione delle autorizzazioni per i dashboard controllati dal codice sorgente

Le autorizzazioni a livello di cartella si applicano a tutti gli oggetti all'interno di tale cartella, inclusi i dashboard. I dashboard in una cartella Git ereditano le autorizzazioni della cartella padre oltre a qualsiasi autorizzazione specifica del dashboard. La maggior parte delle operazioni Git richiede l'autorizzazione CAN MANAGE. Per altre informazioni, vedere ACL di cartella e ACL delle cartelle Git.

Flusso di lavoro di sviluppo consigliato

Clonare il repository nella cartella Git di Databricks, usare rami di funzionalità e inviare richieste pull. La tabella seguente illustra come usare le cartelle Git per gestire i dashboard durante diverse fasi di sviluppo e distribuzione.

Importante

Il cambio di rami Git è un'operazione distruttiva per i dashboard. Azure Databricks rimuove i dashboard che non sono presenti nel ramo di destinazione. Se si torna indietro, i dashboard vengono nuovamente visualizzati con nuovi URL e ID, che interrompe i collegamenti pubblicati, i segnalibri e le integrazioni api. Verificare il ramo di destinazione prima di passare e aggiornare tutti i riferimenti in un secondo momento.

Fase del progetto	Flusso di lavoro	Risultato previsto	Limitazioni note
Commit iniziale	Spostare il dashboard in una cartella Git nell'area di lavoro. Eseguire il commit e il push nel repository Git remoto.	Git tiene traccia del dashboard in un repository remoto.
Sviluppo	Gli sviluppatori creano cartelle Git in rami di sviluppo separati, in genere nelle cartelle principali. Eseguire il commit delle modifiche nel ramo di sviluppo. Unire i rami di sviluppo al main utilizzando le pull request.	Gli sviluppatori lavorano in modo indipendente. Git tiene traccia delle versioni del dashboard.	I file del dashboard usano il JSON formato. Le query SQL vengono visualizzate come una singola riga, che può rendere difficile la revisione delle differenze nelle richieste pull.
Distribuzione	Creare una cartella Git nel ramo di distribuzione in una cartella di primo livello non utente. Vedere CI/CD con le cartelle Git di Databricks. Raccogliere le modifiche nella cartella di distribuzione. Pubblicare le dashboard da questa cartella. Rimuovere modifica+ accesso e limitare gli aggiornamenti a Git. Condividere dashboard con i consumatori.	I consumatori accedono a una versione coerente e pubblicata del dashboard. È possibile condividere i dashboard nella stessa cartella con gruppi di destinatari diversi.	Databricks non offre supporto predefinito per la sincronizzazione di un ramo remoto con una cartella Git nell'area di lavoro o la distribuzione di bundle di asset di Databricks con una risorsa dashboard da remoto. Configurare l'automazione CI/CD per automatizzare: Recupero degli aggiornamenti dal repository remoto. Pubblicazione di dashboard dopo la sincronizzazione. Distribuzione dei bundle di asset di Databricks dopo un aggiornamento.

Per altre procedure consigliate sulla collaborazione nelle cartelle Git di Databricks, vedere Collaborare con le cartelle Git.

Limitazioni

Il controllo del codice sorgente con i dashboard di intelligenza artificiale/BI presenta le limitazioni seguenti:

• È possibile eseguire il commit di un massimo di 100 dashboard in una singola cartella Git. Questo limite potrebbe cambiare durante l'anteprima pubblica.
• I processi basati su Git, ad esempio i processi che fanno riferimento agli URL Git anziché agli ID o ai percorsi degli asset dell'area di lavoro, non funzionano con i dashboard.
• La serializzazione del dashboard genera stringhe lunghe, che rendono difficile la lettura e la revisione delle differenze durante le richieste pull.
• Il formato del file del dashboard cambia periodicamente per includere nuovi campi e altri miglioramenti. Durante l'anteprima pubblica, potreste riscontrare modifiche in Git che non avete avviato.