Controllo del codice sorgente, CI/CD e ALM per agente dati Fabric

Questo articolo descrive come gestire Fabric agenti dati usando pipeline di integrazione e distribuzione Git come parte delle funzionalità di Application Lifecycle Management (ALM) di Microsoft Fabric. Si apprenderà come connettere un'area di lavoro a un repository Git. Si apprenderà anche come tenere traccia delle configurazioni dell'agente dati e della versione. Infine, si apprenderà come promuovere gli aggiornamenti in ambienti di sviluppo, test e produzione. Le pipeline di integrazione e distribuzione Git consentono l'integrazione continua e la distribuzione continua (CI/CD) delle modifiche dell'agente dati, consentendo di testare e promuovere automaticamente gli aggiornamenti come parte del flusso di lavoro ALM. Il controllo del codice sorgente per gli agenti dei dati di Fabric è attualmente in versione di anteprima.

È possibile usare due approcci complementari per supportare ALM per gli agenti dati Fabric:

• Integrazione git: sincronizzare un'intera area di lavoro con un repository Git (Azure DevOps o GitHub come provider Git) per abilitare il controllo della versione, la collaborazione tramite rami e il rilevamento della cronologia per singoli elementi, inclusi gli agenti dati Fabric.
• Pipeline di distribuzione: alzare di livello il contenuto tra aree di lavoro separate che rappresentano fasi di sviluppo, test e produzione usando pipeline predefinite.

Queste funzionalità forniscono insieme supporto end-to-end per ALM agli agenti dati di Fabric.

Prerequisiti

• Una capacità di Fabric a pagamento di livello F2 o superiore, o una capacità Power BI Premium per capacità (P1 o superiore) con Microsoft Fabric abilitato.
• Abilitare l'elaborazione tra aree geografiche e l'archiviazione tra aree geografiche per l'intelligenza artificiale in base ai requisiti illustrati nelle impostazioni del tenant dell'agente dati di Fabric.
• Almeno una di queste origini dati, con dati: un warehouse, una lakehouse, un modello semantico di Power BI, un database KQL, un database con mirroring o un'ontologia. È necessario disporre dell'accesso in lettura all'origine dati.

Integrazione Git

Microsoft Fabric l'integrazione di Git sincronizza un'area di lavoro Fabric con un repository Git, consentendo di usare i processi di sviluppo, gli strumenti e le procedure consigliate esistenti direttamente nella piattaforma Fabric. Supporta Azure DevOps e GitHub ed è disponibile a livello di area di lavoro. Quando si esegue il commit delle modifiche da Fabric, inclusi gli aggiornamenti alla configurazione dell'agente dati, tali modifiche vengono salvate come file nel repository Git connesso. Le funzionalità principali includono:

• Backup completo e controllo della versione degli elementi dell'area di lavoro
• La struttura di cartelle in Git rispecchia la struttura dell'area di lavoro
• Le configurazioni dell'agente dati (selezione dello schema, istruzioni di intelligenza artificiale, istruzioni sull'origine dati, query di esempio) vengono archiviate in file strutturati in cartelle dedicate
• Possibilità di visualizzare le differenze, esaminare la cronologia e ripristinare gli stati precedenti tramite cronologia per diversi elementi dell'area di lavoro, inclusi gli agenti dati
• Collaborazione basata su rami (rami delle funzionalità, principale)

Miglioramenti più recenti dell'integrazione git

L'integrazione Git di Fabric ora supporta il branching selettivo, consentendo di modificare il branch connesso a livello di workspace per allinearsi ai workflow dei feature branch. Il riquadro Controllo del codice sorgente offre anche un'esperienza diff predefinita per le modifiche degli elementi, in modo da poter esaminare esattamente le modifiche apportate prima di eseguire il commit o il pull degli aggiornamenti. Le aree di lavoro con rami sono più chiaramente indicate nell'interfaccia utente Fabric, semplificando l'identificazione del ramo a cui è connessa ogni area di lavoro.

Per altre informazioni sul processo di integrazione Git, è possibile fare riferimento alle risorse seguenti.

• Che cos'è Microsoft Fabric integrazione Git?
• Concetti di base nell'integrazione Git
• Introduzione all'integrazione con Git

Configurare una connessione al controllo del codice sorgente

È possibile connettere l'area di lavoro Fabric a un repository Git dalla pagina delle impostazioni Workspace. Questa connessione consente di eseguire il commit e la sincronizzazione delle modifiche direttamente da Fabric.

1. Vedere Introduzione all'integrazione git per informazioni dettagliate sulla connessione a un repository Git in Azure DevOps o GitHub.

2. Dopo la connessione al repository Git, gli elementi dell'area di lavoro, inclusi gli agenti di dati Fabric, vengono visualizzati nel pannello di controllo del codice sorgente. Nella barra di stato in basso a sinistra è possibile visualizzare il nome del ramo connesso, l'ora dell'ultima sincronizzazione e l'ID commit Git.

3. Il repository Git collegato visualizza una struttura di cartelle che rappresenta gli elementi dell'area di lavoro, inclusi gli agenti dati Fabric e i relativi file di configurazione. Ogni agente dati viene archiviato nella propria cartella, consentendo di esaminare le modifiche, tenere traccia della cronologia delle versioni e usare flussi di lavoro Git, ad esempio la creazione di richieste pull per unire gli aggiornamenti nel ramo principale.

4. Quando si apportano modifiche all'agente dati Fabric in un'area di lavoro connessa a Git, vengono rilevate le modifiche e lo stato dell'agente dati nel riquadro Controllo del codice sorgente cambia in Modifiche di cui non è stato eseguito il commit. Queste modifiche possono includere:

   • Modifica della selezione dello schema.
   • Aggiornamento delle istruzioni di intelligenza artificiale o delle istruzioni sull'origine dati.
   • Modifica query di esempio.
   • Pubblicazione dell'agente dati o aggiornamento della relativa descrizione di pubblicazione.

Qualsiasi modifica, sia funzionale che descrittiva, causa una disallineamento dell'agente dei dati con il repository Git collegato. Gli elementi dell'area di lavoro con modifiche verranno visualizzati nella scheda Modifiche nel riquadro Controllo del codice sorgente. È possibile esaminare queste modifiche, confrontarle con la versione già salvata e rieffettuarne il commit nel repository Git per sincronizzazione.

5. Quando gli aggiornamenti vengono eseguiti direttamente nel repository Git collegato (Azure DevOps o GitHub), possono includere azioni come la modifica di istruzioni di intelligenza artificiale, la modifica di query di esempio o la modifica delle descrizioni della pubblicazione. È quindi possibile eseguire il commit e il push di tali modifiche nel repository. Dopo aver eseguito il push degli aggiornamenti e averli resi disponibili nel repository, l'area di lavoro Fabric li rileva e visualizza una notifica Aggiornamenti disponibile nel riquadro Controllo del codice sorgente. Gli elementi aggiornati, ad esempio l'agente dati, vengono visualizzati nella scheda Aggiornamenti, in cui è possibile esaminarli e accettarli. L'accettazione di questi aggiornamenti applica le modifiche del repository agli elementi dell'area di lavoro, assicurando che l'area di lavoro rifletta la versione di cui è stato eseguito il commit più recente in Git.

Struttura di directory e file nel repository Git

Di seguito viene esaminata la struttura della modalità di archiviazione della configurazione di un agente dati in un repository Git. Comprendere questa struttura è importante per gestire le modifiche e seguire le procedure consigliate. Quando si usano rami di funzionalità, apportare modifiche nel ramo associato all'area di lavoro, esaminare le differenze nel riquadro Controllo del codice sorgente e unire tramite richieste pull per l'innalzamento di livello controllato. I file e la struttura di configurazione per gli agenti dati rimangono invariati tra i rami.

Struttura radice

Nella radice il contenuto dell'agente dati viene archiviato nella cartella files . All'interno dei file si trova una cartella config , che contiene data_agent.json, publish_info.json, la cartella bozza e la cartella pubblicata.

All'interno della cartella config , il publish_info.json contiene la descrizione di pubblicazione per l'agente dati. Questo file di configurazione può essere aggiornato per cambiare la descrizione visualizzata quando viene pubblicato l'agente dati.

La cartella bozza contiene i file di configurazione corrispondenti alla versione bozza dell'agente dati e la cartella pubblicata contiene i file di configurazione per la versione pubblicata dell'agente dati. La cartella delle bozze contiene:

• Cartelle origine dati in cui è presente una cartella per ogni origine dati usata dall'agente dati.
  • Origini dati lakehouse o warehouse: i nomi delle cartelle iniziano con lakehouse-tables- o warehouse-tables-, seguiti dal nome del lakehouse o del magazzino.
  • Origini dati del modello semantico: i nomi delle cartelle iniziano con semantic-model-, seguito dal nome del modello semantico.
  • Origini dati del database KQL: i nomi delle cartelle iniziano con kusto-, seguito dal nome del database KQL.
  • Origini dati di ontologia: i nomi delle cartelle iniziano con ontology-, seguito dal nome dell'ontologia.

• stage_config.json che contiene aiInstructions, che fa riferimento alle istruzioni dell'agente.

Ogni cartella dell'origine dati contiene datasource.json e fewshots.json. Tuttavia, se l'origine dati è un modello semantico, non supporta query di esempio, pertanto la relativa cartella contiene solo datasource.json.

Il datasource.json definisce la configurazione per l'origine dati, tra cui:

• dataSourceInstructions, che rappresenta le istruzioni fornite per l'origine dati.

• displayName, che mostra il nome dell'origine dati.

• elements, che fa riferimento alla mappa dello schema e include un elenco completo di tabelle e colonne dall'origine dati.

  • Ogni tabella ha una is_selected proprietà . Se true, la tabella è inclusa e, se false, significa che la tabella non è selezionata e non verrà usata dall'agente dati.
  • Le voci di colonna mostrano anche is_selected, ma la selezione a livello di colonna non è attualmente supportata. Se è selezionata una tabella, tutte le relative colonne vengono incluse indipendentemente dal valore della colonna is_selected . Se una tabella non è selezionata (is_selected: false a livello di tabella), nessuna delle colonne viene considerata nonostante sia is_selected impostata su true a livello di colonna.

• Convenzioni dei tipi:

  • Se il tipo è un'origine dati, è semplicemente il tipo di origine dati (ad esempio: "type": "lakehouse_tables").
  • Se il tipo è una tabella, termina con .table (ad esempio: "type": "lakehouse_tables.table").
  • Se il tipo è una colonna, termina con .column (ad esempio: "type": "lakehouse_tables.column").

Il fewshots.json archivia query di esempio per l'origine dati. Ogni voce include:

• id come identificatore univoco per la query di esempio.
• question, che fa riferimento alla domanda del linguaggio naturale.
• query mostra il testo della query, che può essere SQL o KQL a seconda del tipo di origine dati.

La cartella pubblicata rispecchia la struttura della cartella delle bozze, ma rappresenta la versione pubblicata dell'agente dei dati. È consigliabile non modificare direttamente i file nella cartella pubblicata. Le modifiche devono essere apportate nella cartella bozza. Dopo la pubblicazione dell'agente dati, tali modifiche vengono riflesse nella cartella pubblicata. In questo modo si garantisce che la versione pubblicata venga sempre generata da uno stato bozza controllato.

Pipeline di implementazione per agenti di dati

Le pipeline di distribuzione offrono un modo controllato per spostare gli agenti dati tra aree di lavoro mappate a diverse fasi del ciclo di vita. Per esempio:

1. Sviluppare un nuovo agente dati o aggiornare uno esistente nell'area di lavoro di sviluppo.
2. Promuovere le modifiche nel workspace di test per la convalida.
3. Pubblicare le modifiche testate nell'area di lavoro di produzione dove sono disponibili per gli utenti finali.

Prima della distribuzione, è necessario assegnare un'area di lavoro a ogni fase della pipeline di distribuzione: sviluppo, test e produzione. Se non si assegna un'area di lavoro alla fase di test o produzione, le aree di lavoro vengono create automaticamente. Le aree di lavoro create automaticamente sono denominate dopo l'area di lavoro di sviluppo, con [test] o [prod] accodati.

Per distribuire le modifiche:

• Nella pipeline passare alla fase da cui si vuole eseguire la distribuzione( ad esempio, sviluppo).
• Selezionare gli elementi nell'area di lavoro da distribuire.
• Selezionare Distribuisci per promuoverli allo stadio successivo.

È possibile esaminare un piano di distribuzione prima di applicare le modifiche, assicurandosi che vengano alzati di livello solo gli aggiornamenti previsti. Per ulteriori informazioni, consultare Introduzione alle pipeline di distribuzione.

Automatizzare CI/CD con pipeline di Azure DevOps

L'estensione Azure DevOps Pipelines per Fabric fornisce attività native che eseguono comandi Fabric CLI nei processi della pipeline di Azure DevOps. I team possono orchestrare CI/CD per gli aggiornamenti dell'agente dati usando Azure DevOps (con il CLI) insieme o anziché le pipeline di distribuzione Fabric. Per iniziare, installare l'estensione da Visual Studio Marketplace, configurare una connessione al servizio nel progetto Azure DevOps e aggiungere attività dell'interfaccia della riga di comando Fabric alla definizione della pipeline.

Sincronizzazione in blocco tramite API batch (anteprima)

Le API Batch Import/Export Item Definitions (anteprima) offrono un'opzione per la sincronizzazione su larga scala delle definizioni degli elementi, incluse le configurazioni dell'agente dati. È possibile esportare e importare le definizioni dell'agente dati in batch per semplificare l'innalzamento di livello tra gli ambienti. Per altre informazioni, vedere la documentazione dell'API REST Fabric.

Pubblicare un agente dati Fabric per le pipeline di distribuzione

La pubblicazione di un agente dati Fabric lo rende disponibile per l'uso in tutti i diversi canali di consumo, inclusi Copilot per gli strumenti di Power BI, Microsoft Copilot Studio e Foundry. Per valutare e utilizzare l'agente dati in questi canali, l'agente dati deve essere pubblicato; Gli agenti dati non pubblicati non sono accessibili per l'utilizzo anche se si trovano nell'area di lavoro di produzione. Per seguire le procedure consigliate in base alla pipeline di distribuzione, tenere presente che:

• La pubblicazione da un'area di lavoro di sviluppo deve essere limitata solo agli utenti autorizzati che lavorano allo sviluppo dell'agente dati e vogliono valutarne le prestazioni in diversi canali di consumo. L'accesso a questo spazio di lavoro deve essere limitato in modo che gli agenti di dati in fase di sviluppo o sperimentali non vengano esposti a un ampio pubblico.
• Gli utenti finali devono accedere agli agenti dati pubblicati solo dall'area di lavoro di produzione, assicurandosi di interagire con versioni stabili e approvate dell'agente dati.

Questo approccio supporta sia il requisito funzionale di abilitazione della valutazione dell'utilizzo che delle prestazioni e garantisce un controllo di accesso appropriato mantenendo separati gli ambienti di sviluppo e produzione.

Procedure consigliate

• Usare un ramo dedicato per il lavoro di sviluppo sugli agenti dati e unirlo a main dopo la revisione del codice.
• Mantenere le risorse correlate (origini dati, agenti dati, notebook, pipeline) nella stessa area di lavoro per una promozione più semplice.
• Prima di promuoverlo in produzione, apportare modifiche all'agente dati di test nell'area di lavoro di test.
• Usare messaggi di commit descrittivi per semplificare la comprensione della cronologia.
• Non apportare direttamente modifiche alla cartella pubblicata nel repository Git.
• Usare modelli di configurazione indipendenti dall'ambiente (ad esempio, riferimenti di connessione tramite libreria di variabili dove supportato) per evitare di inserire codificato valori specifici dell'ambiente nelle configurazioni delle origini dati dell'agente. Questa procedura facilita le unioni e le distribuzioni di rami più fluide tra sviluppo, test e produzione.

Limitazioni e considerazioni

• Solo le aree di lavoro connesse a un repository Git possono usare le funzionalità ALM basate su Git.
• I principali del servizio sono supportati nell'agente dati Fabric solo come parte degli scenari ALM. Se è necessario interagire con un agente dati all'esterno dei flussi di lavoro ALM, il service principal non è supportato.
• Le pipeline di distribuzione richiedono che le aree di lavoro di origine e di destinazione si trovino nello stesso tenant.
• Un numero elevato di commit frequenti può influire sulle dimensioni e sulle prestazioni del repository.

Contenuti correlati

• Introduzione all'integrazione con Git
• Concetti di base nell'integrazione Git
• Che cos'è la gestione del ciclo di vita in Microsoft Fabric?