Scegliere l'opzione migliore per il workflow CI/CD di Fabric

Questo articolo presenta agli sviluppatori Fabric diverse opzioni per costruire processi CI/CD in Fabric, basate su scenari comuni dei clienti. Questo articolo è incentrato maggiormente sulla distribuzione continua (CD) del processo CI/CD. Per una discussione sulla parte dell'integrazione continua (CI), vedi Processo di sviluppo in Microsoft Fabric.

Anche se questo articolo descrive diverse opzioni, molte organizzazioni accettano un approccio ibrido.

Prerequisiti

Per creare un processo CI/CD usando le opzioni in questo articolo, è necessario:

• Sottoscrizione di Microsoft Fabric

• Un'area di lavoro Fabric (è necessario essere un amministratore dell'area di lavoro per configurare la distribuzione)

• Per le opzioni basate su Git (1, 2 e 4), un provider Git supportato (Azure DevOps o GitHub) connesso tramite l'integrazione Git

Processo di sviluppo

Il processo di sviluppo è lo stesso in tutti gli scenari di distribuzione ed è indipendente da come rilasciare nuovi aggiornamenti nell'ambiente di produzione. Quando gli sviluppatori lavorano con il controllo del codice sorgente, devono lavorare in un ambiente isolato. In Fabric, tale ambiente può essere un IDE nel computer locale (ad esempio Power BI Desktop o VS Code) o un'area di lavoro diversa in Fabric. Puoi trovare informazioni sulle diverse considerazioni per il processo di sviluppo in Processo di sviluppo in Microsoft Fabric.

La sincronizzazione Git supporta sia il commit delle modifiche dello spazio di lavoro su Git sia l'aggiornamento di uno spazio di lavoro da Git. La freccia PR mostra la direzione in cui unisci i cambiamenti di funzionalità nel ramo di sviluppo condiviso, non un'operazione di sincronizzazione bidirezionale.

Processo di rilascio

Il processo di rilascio viene avviato una volta completati i nuovi aggiornamenti e la richiesta pull (PR) viene unita al ramo condiviso del team( ad esempio Main, Dev e così via). Da questo punto sono disponibili diverse opzioni per compilare un processo di rilascio in Fabric.

La tabella seguente riepiloga le opzioni che consentono di scegliere. Molti team combinano più di uno.

¹ Nell'opzione 2, solo lo spazio di lavoro Dev è collegato a Git. Gli spazi di lavoro Test e Prod non sono collegati a Git. Eseguire il push di un tag di release su Main attiva una pipeline che distribuisce quella versione a Test. Dopo la validazione e l'approvazione riuscite, la pipeline distribuisce lo stesso tag e il commit SHA su Prod.

Queste opzioni non richiedono una strategia specifica di ramificazione, come Gitflow o sviluppo basato su trunk. Ciò che conta è che ogni fase distribuisce un commit noto e versionato, e che il Prod riceva lo stesso contenuto che hai testato.

Le opzioni 1 e 2 differiscono nel modo in cui organizzi e promuovi le release, non in una scelta esclusiva di strumenti. Entrambe le opzioni possono utilizzare API fabric-cicd o Fabric Items e parametrizzazione specifica per ambiente. L'opzione 1 propaga le modifiche tramite rami di fase separati. L'opzione 2 utilizza un release tag su Main per attivare il deployment dello stesso commit al Test e, dopo validazione e approvazione, al Prod.

Un piano di distribuzione non è un'opzione di flusso di lavoro separata. Puoi utilizzare un piano con operazioni Git supportate nell'opzione 1, con pipeline di distribuzione nell'opzione 3, oppure chiamando direttamente l'API Bulk Import Item Definitions nelle opzioni 1, 2 e 4. La fabric-cicd libreria non supporta piani di distribuzione, anche quando usi la modalità di importazione in massa. Il piano controlla l'ordine di implementazione, le dipendenze e le azioni, mentre il flusso di lavoro selezionato continua a definire la fonte di verità, cosa implementa ogni stadio e la configurazione dello stadio.

Opzione 1 - Distribuzioni basate su definizioni da rami Git per fase

Con questa opzione, tutte le distribuzioni hanno origine da Git. Ogni fase ha un ramo primario dedicato: Dev, Test e Prod in questo esempio. I PR promuovono cambiamenti tra quei rami e ogni workspace riceve le definizioni dal branch della propria fase. Puoi distribuire con Git Integration, fabric-cicd o API Fabric Items. Quando usi fabric-cicd o Items API, lo spazio di lavoro di destinazione non ha bisogno di una connessione Git. La caratteristica distintiva è il ramo separato per ogni stadio, non lo strumento di distribuzione.

Quando una richiesta pull è approvata e fusa nel ramo Dev:

1. Aggiorna lo spazio di lavoro Dev dal Dev branch, ad esempio con l'integrazione di Git. Esegui test unitari e tutte le operazioni necessarie dopo il deployment.
2. Crea una PR al branch Test con le modifiche che vuoi promuovere. Puoi usare un ramo di rilascio per cherry-pickare quei cambiamenti. Applica i processi di revisione e approvazione del tuo team.
3. Distribuisci un commit specifico dal ramo Test allo spazio di lavoro Test utilizzando API di integrazione Git, fabric-cicd o Fabric Items. Applica configurazioni specifiche per stadio ed esegui test automatizzati o manuali.
4. Crea una PR per il ramo Prod che promuova i cambiamenti convalidati. Rivedere le definizioni risultanti per assicurarti che corrispondano al rilascio testato, tranne che per le configurazioni intenzionalmente specifiche per uno stage. Se aggiungi altre modifiche, validale in Test prima della promozione.
5. Dopo l'approvazione, distribuisci il ramo Prod nello spazio di lavoro Prod utilizzando lo strumento di distribuzione selezionato da te. Esegui i controlli post-deployment e le operazioni di ingestione dati richiesti.

Alcune dipendenze dagli elementi si legano automaticamente tramite ID logici. Altri necessitano di parametrizzazione o aggiornamenti post-deployment. Per ulteriori informazioni, consulta Comprendere il binding delle dipendenze nella distribuzione tra aree di lavoro.

Quali componenti possono essere usati per implementare l'opzione #1?

• Integrazione Git: collega ogni spazio di lavoro al suo branch stage. Aggiornalo tramite l'interfaccia di Fabric o automatizza gli aggiornamenti con le API di Fabric Git.
• Fabric-CICD: Effettua il checkout del branch della fase e pubblica le definizioni degli elementi con parametri specifici per l'ambiente. Lo spazio di lavoro target non ha bisogno di una connessione Git.
• API Fabric Items: Distribuisci le definizioni dal branch dello stage chiamando Create item and Update item definition, oppure l'API Bulk Import Item Definitions. Quando chiami direttamente le API, la tua automazione prepara le definizioni e la configurazione specifica della fase.

Per esempi di implementazione, consulta il tutorial fabric-cicd e Azure DevOps o Fabric CI/CD con l'API Bulk Import Item Definitions.

Quando è consigliabile usare l'opzione 1?

• Quando si desidera utilizzare il repository Git come unica fonte di verità e origine di tutte le implementazioni.
• Quando vuoi un ramo principale separato per ogni fase, con revisione e promozione basate sulle PR tra le fasi.
• Quando vuoi gestire definizioni specifiche per fase in Git, oppure applicare configurazioni specifiche per ambiente con lo strumento di distribuzione che hai selezionato.

Opzione 2 - Implementazioni basate su definizioni da un commit di release condiviso

Con questa opzione, gli sviluppatori lavorano su un Dev branch collegato allo spazio di lavoro Dev . Il ramo principale è il ramo di rilascio: contiene solo le modifiche che scegli di rilasciare. Gli spazi di lavoro Test e Prod non sono collegati a Git. Eseguire il push di un tag di rilascio su Main attiva un workflow di GitHub Actions o una pipeline di Azure DevOps. Distribuisce la versione taggata su Test, esegue la validazione e attende l'approvazione della produzione prima di distribuire lo stesso tag e il commit SHA su Prod. La pipeline potrebbe utilizzare un ambiente di compilazione per eseguire test unitari e modificare le definizioni degli elementi prima di caricarle. Ad esempio, potresti cambiare connessioni alla sorgente dati, riferimenti ad altri elementi o valori dei parametri per la fase target. Non tutte le dipendenze dagli elementi richiedono questi cambiamenti. Alcuni si collegano automaticamente tramite ID logici quando vengono distribuiti in una nuova area di lavoro. Per ulteriori informazioni, consulta Comprendere il binding delle dipendenze nella distribuzione tra aree di lavoro.

Il flusso di rilascio funziona come segue:

1. Gli sviluppatori uniscono i PR approvati nel ramo Dev , e lo spazio di lavoro Dev viene aggiornato da Git.
2. Per preparare una release, crea una PR che fa il cherry-pick delle modifiche che vuoi rilasciare da Dev a Main. La PR dovrebbe includere gli stessi processi di revisione e approvazione di qualsiasi altro PR nel tuo team o organizzazione.
3. Crea un tag release sul commit scelto su Main, ad v1.5.0esempio. Esegui il push del tag per attivare un workflow GitHub Actions o una pipeline Azure DevOps configurata per i tag di rilascio.
4. La pipeline risolve il tag in un commit SHA, registra entrambi, effettua il checkout di quel commit, esegue test unitari e aggiusta la configurazione per Test. Carica queste definizioni di elementi nell'area di lavoro Test utilizzando fabric-cicd o l'API Bulk Import Item Definitions. Per dettagli, vedi Quali componenti possono essere utilizzati per implementare l'opzione #2?. Esegui test automatici o manuali dopo il deployment. Se la validazione fallisce, ferma la promozione a Prod.
5. Dopo che la validazione è riuscita, la pipeline attende in un gate di approvazione di produzione configurato. Usa un'approvazione dell'ambiente GitHub o un controllo di approvazione dell'ambiente Azure DevOps.
6. Dopo l'approvazione, distribuire lo stesso release tag e lo stesso commit SHA registrato su Prod. Solo la configurazione per stadio, come i set di valori della libreria variabile o i file di parametri, differisce da Test. Esegui controlli specifici per la produzione e attiva qualsiasi ingestione di dati richiesta dal cambiamento per minimizzare l'indisponibilità per i consumatori.

Se la validazione fallisce, fai prima la correzione in Dev e poi esegui il cherry-pick in Main. Crea un nuovo release tag e ripeti la pipeline, inclusa la validazione dei test. Questo approccio garantisce anche che le future release di Dev includano la correzione.

Per la tracciabilità, configura i job di distribuzione per puntare agli ambienti corrispondenti di GitHub o di Azure DevOps. Includere il release tag e il commit SHA risolto in ogni record di deployment così puoi identificare quale versione è arrivata a Test e Prod. Un tag Git da solo non registra dove è stata distribuita una versione.

Quali componenti possono essere usati per implementare l'opzione 2?

• Fabric-cicd : una libreria Python progettata per l'uso con le aree di lavoro di Microsoft Fabric. Questa libreria supporta le automazione di integrazione continua/distribuzione continua (CI/CD) code-first per integrare facilmente le aree di lavoro in un framework di distribuzione. Per un esempio completo dall'inizio alla fine, segui la l'esercitazione su fabric-cicd e Azure DevOps. Fabric-CICD supporta due modalità di pubblicazione:
  • API di definizione di elemento (predefinite): Pubblicano gli elementi uno alla volta utilizzando le API di Fabric Crea elemento e Aggiorna definizione elemento.
  • Importazione in massa (sperimentale): Pubblica tutti gli elementi in un'unica chiamata utilizzando l'API Bulk Import Item Definitions. Per usare questa modalità, abilita i flag di funzionalità enable_experimental_features e enable_bulk_publish. Per maggiori informazioni, vedi Fabric-CICD Bulk Publish.
• Bulk-Import-Item-Definitions-API: l'API supporta sia la creazione di nuovi elementi che l'aggiornamento di quelli esistenti, mentre si basa sulla gestione delle dipendenze predefinita di Fabric per assicurarsi che gli elementi vengano distribuiti nell'ordine corretto. Ciò consente distribuzioni coerenti e ripetibili in ambienti di test e produzione senza intervento manuale. Per un'esercitazione di esempio, segui la nostra guida API CI/CD con l'API di Definizioni di Elementi per Importazione Massiva di Fabric.

Quando è consigliabile usare l'opzione 2?

• Quando serve la parametrizzazione specifica dell'ambiente delle definizioni degli elementi prima del deployment. La funzione di parametrizzazione fabric-cicd utilizza un parameter.yml file per sostituire i valori di ogni ambiente target, inclusi ID di connessione e ID lakehouse, senza mantenere definizioni separate di elemento per ogni stadio. Supporta operazioni di ricerca e sostituzione, sostituzione di valori selezionati dai percorsi JSON e risoluzione dinamica degli ID degli elementi dello spazio di lavoro target. Questa funzionalità è disponibile anche nell'opzione 1 quando si utilizza Fabric-CICD. L'integrazione di Git da sola non fornisce questa sostituzione al momento del deployment.
• Quando vuoi usare Git come unica fonte di verità e origine di tutte le distribuzioni.
• Quando vuoi scegliere quali modifiche inserire in ogni release e distribuire una versione taggata e testata su Prod.

Opzione 3 - Distribuire usando le pipeline di distribuzione di Fabric

Con questa opzione, Git è connesso solo fino allo stadio di sviluppo. Dalla fase di sviluppo , le distribuzioni vengono eseguite direttamente tra le aree di lavoro di Sviluppo/Test/Prod, usando le pipeline di distribuzione di Fabric. Puoi distribuire tra le fasi direttamente dall'interfaccia Fabric, oppure usare le API delle pipeline di distribuzione per orchestrare il deployment come parte della pipeline di release Azure, o un workflow su GitHub. Queste API consentono al team di creare un processo di compilazione e rilascio simile come in altre opzioni, usando test automatizzati (che possono essere eseguiti nell'area di lavoro stessa o prima della fase di sviluppo), approvazioni e così via.

Quando il dispiegamento richiede un ordine specifico, elementi correlati o azioni, puoi allegare un piano di dispiegamento a un dispiegamento tra le fasi. Le regole di distribuzione e l'autobinding continuano a gestire la configurazione specifica per stadio.

Quando approvi e unisci un PR al branch collegato al workspace Dev:

1. Aggiorna lo spazio di lavoro Dev da Git usando l'interfaccia utente di Fabric o le API Git di Fabric. Esegui tutte le operazioni e i test necessari dopo l'aggiornamento.
2. Distribuisci le modifiche da Dev a Test utilizzando pipeline di distribuzione Fabric, sia dall'interfaccia utente Fabric sia tramite le API delle pipeline di distribuzione. Esegui test automatizzati o manuali in Test prima di promuovere le modifiche a Prod.
3. Dopo che i test sono passati e il release manager ha approvato, distribuisci il contenuto validato da Test a Prod. Non aggiornare il contenuto selezionato in Test tra la validazione e il deployment su Prod senza testarlo di nuovo.

Puoi eseguire questi passaggi dall'interfaccia Fabric o automatizzarli con API in Azure Pipelines o GitHub Actions. Non servono pipeline di build e release esterne per il flusso di lavoro basato sull'interfaccia.

Quando è consigliabile usare l'opzione 3?

• Quando il tuo team preferisce l'esperienza di implementazione integrata di Fabric e le sue capacità rispondono alle tue esigenze di implementazione. Puoi distribuire contenuti tra aree di lavoro dall'interfaccia Fabric senza mantenere pipeline di rilascio esterne e usare API per l'automazione quando necessario. Questo approccio può anche adattarsi a team con esperienza limitata con strumenti DevOps, come Azure Pipelines o GitHub Actions.
• Quando si usa il controllo del codice sorgente solo a scopo di sviluppo e si preferisce distribuire le modifiche direttamente tra le fasi della pipeline di versione.
• Quando le regole di distribuzione, l'associazione automatica e altre API disponibili sono sufficienti per gestire le configurazioni tra le fasi della pipeline di versione.
• Quando si vogliono usare altre funzionalità delle pipeline di distribuzione di Fabric, ad esempio la visualizzazione delle modifiche in Infrastruttura, la cronologia di distribuzione e così via.
• Si consideri anche che le distribuzioni nelle pipeline di distribuzione di Fabric abbiano una struttura lineare e richiedano altre autorizzazioni per creare e gestire la pipeline.

Opzione 4 - CI/CD per ISV in Fabric (gestione di più clienti/soluzioni)

Questa opzione è diversa dalle altre. È più rilevante per i fornitori di software indipendenti (ISV) che creano applicazioni SaaS per i propri clienti su Fabric. Gli ISV hanno in genere un'area di lavoro separata per ogni cliente e possono avere un numero di centinaia o migliaia di aree di lavoro. Quando la struttura dell'analisi fornita a ogni cliente è simile e standard, è consigliabile avere un processo di sviluppo e test centralizzato che viene suddiviso per ciascun cliente solo nella fase Prod.

Questa opzione si basa sull'opzione #2:

1. Gli sviluppatori lavorano sul ramo Dev e sullo spazio di lavoro Dev, eseguendo il cherry-pick delle modifiche che vogliono rilasciare da Dev a Main, come descritto nell'opzione #2.
2. Creare e spingere un release tag sul commit scelto su Main, ad v1.5.0esempio . Il tag attiva un flusso di lavoro GitHub Actions o una pipeline Azure DevOps.
3. La pipeline risolve il tag in un commit SHA, registra entrambi, esegue test unitari e modifica le definizioni associate al tag per il Test condiviso. Li distribuisce utilizzando fabric-cicd o l'API Bulk Import Item Definitions, come descritto nell'opzione #2. Esegui test automatici o manuali dopo il deployment. Se la validazione fallisce, ferma la promozione, risolvi il problema nello Dev, porta la correzione in Main e crea un nuovo tag per un'altra run.
4. Dopo che la validazione ha avuto successo e l'approvazione di produzione configurata è stata concessa, distribuisci lo stesso tag e lo SHA di commit registrato nello spazio di Prod di ogni cliente. Applica parametri e connessioni specifici per il cliente prima del deployment o tramite API post-deployment. Le implementazioni indipendenti dei clienti possono funzionare in parallelo. Registra il tag, il commit SHA e il target del cliente nella cronologia di distribuzione dell'ambiente in modo che la versione distribuita di ogni cliente sia tracciabile.

Quando è consigliabile usare l'opzione 4?

• Sei un ISV che sviluppa applicazioni su Fabric.
• Si usano aree di lavoro diverse per ogni cliente per gestire la multi-tenancy dell'applicazione
• Per una maggiore separazione o per test specifici per clienti diversi, potrebbe essere necessario avere la multi-tenancy nelle fasi precedenti dello sviluppo o del test. In tal caso, tenere presente che con multi-tenancy il numero di aree di lavoro necessarie aumenta in modo significativo.

Riepilogo

Questo articolo riepiloga le principali opzioni CI/CD per un team che vuole creare un processo CI/CD automatizzato in Fabric. Mentre vengono delineate quattro opzioni, i vincoli reali e l'architettura della soluzione possono prestarsi a opzioni ibride o completamente diverse. È possibile usare questo articolo per esaminare le diverse opzioni e come compilarle, ma non è necessario scegliere solo una delle opzioni.

Alcuni scenari o elementi specifici potrebbero presentare limitazioni che possono impedire l'adozione di uno di questi scenari.

Lo stesso vale per gli strumenti. Anche se qui vengono menzionati diversi strumenti, è possibile scegliere altri strumenti che possono fornire lo stesso livello di funzionalità. Si consideri che Fabric abbia una migliore integrazione con alcuni strumenti, quindi la scelta di altri comporta maggiori limitazioni che richiedono soluzioni alternative diverse.

Contenuto correlato

• Processo di sviluppo in Microsoft Fabric
• Automatizzare l'integrazione di Git usando le API e Azure DevOps
• Automatizzare la pipeline di distribuzione usando le API di infrastruttura
• Comprendere l'associazione delle dipendenze nella distribuzione tra aree di lavoro
• Qual è un piano di distribuzione in Microsoft Fabric?