Condividi tramite

Scegliere l'opzione migliore per il flusso di lavoro CI/CD dell'infrastruttura

  • Articolo

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 distribuzione continua (CD) del processo CI/CD. Per una discussione sulla parte integrazione continua (CI), vedere Gestire i rami Git.

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

Prerequisiti

Per accedere alla funzionalità delle pipeline di distribuzione è necessario soddisfare le condizioni seguenti:

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 Infrastruttura 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. È possibile trovare informazioni sulle diverse considerazioni relative al processo di sviluppo in Gestire i rami Git

Diagramma che mostra il funzionamento del processo di sviluppo.

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.

Opzione 1 - Distribuzioni basate su Git

Diagramma che mostra il funzionamento della distribuzione basata su Git.

Con questa opzione, tutte le distribuzioni provengono dal repository Git. Ogni fase della pipeline di versione ha un ramo primario dedicato (nel diagramma queste fasi sono Sviluppo, Test e Prod), che alimenta l'area di lavoro appropriata in Fabric.

Dopo l'approvazione e l'unione di una richiesta pull al ramo dev :

  1. Viene attivata una pipeline di versione per aggiornare il contenuto dell'area di lavoro Sviluppo . Questo processo può includere anche una pipeline di compilazione per eseguire unit test, ma il caricamento effettivo dei file viene eseguito direttamente dal repository nell'area di lavoro, usando le API Git di Fabric. Potrebbe essere necessario chiamare altre API di Fabric per le operazioni post-distribuzione che impostano configurazioni specifiche per questa area di lavoro o inseriscono dati.
  2. Viene quindi creata una richiesta pull al ramo Test . Nella maggior parte dei casi, la richiesta pull viene creata usando un ramo di versione in grado di selezionare il contenuto da spostare nella fase successiva. La richiesta pull deve includere gli stessi processi di revisione e approvazione di qualsiasi altro membro del team o dell'organizzazione.
  3. Viene attivata un'altra pipeline di compilazione e versione per aggiornare l'area di lavoro Test , usando un processo simile a quello descritto nel primo passaggio.
  4. Viene creata una richiesta pull per il ramo Prod , usando un processo simile a quello descritto nel passaggio 2.
  5. Viene attivata un'altra pipeline di compilazione e versione per aggiornare l'area di lavoro Prod , usando un processo simile a quello descritto nel primo passaggio.

Quando è consigliabile usare l'opzione 1?

  • Quando si vuole usare il repository Git come singola origine di verità e l'origine di tutte le distribuzioni.
  • Quando il team segue Gitflow come strategia di diramazione, inclusi più rami primari.
  • Il caricamento dal repository passa direttamente nell'area di lavoro, perché non sono necessari ambienti di compilazione per modificare i file prima delle distribuzioni. È possibile modificarlo chiamando le API o eseguendo elementi nell'area di lavoro dopo la distribuzione.

Opzione 2 - Distribuzioni basate su Git con ambienti di compilazione

Diagramma che mostra il flusso della distribuzione basata su Git usando gli ambienti di compilazione.

Con questa opzione, tutte le distribuzioni provengono dallo stesso ramo del repository Git (Main). Ogni fase nella pipeline di versione include una pipeline di compilazione e versione dedicata. Queste pipeline possono usare un ambiente di compilazione per eseguire unit test e script che modificano alcune delle definizioni negli elementi prima del caricamento nell'area di lavoro. Ad esempio, è possibile modificare la connessione all'origine dati, le connessioni tra gli elementi nell'area di lavoro o i valori dei parametri per modificare la configurazione per la fase corretta.

Dopo l'approvazione e l'unione di una richiesta pull al ramo di sviluppo :

  1. Viene attivata una pipeline di compilazione per avviare un nuovo ambiente di compilazione ed eseguire unit test per la fase di sviluppo . Viene quindi attivata una pipeline di versione per caricare il contenuto in un ambiente di compilazione, eseguire script per modificare alcune configurazioni, modificare la configurazione in fase di sviluppo e usare le API di definizione dell'elemento di aggiornamento di Fabric per caricare i file nell'area di lavoro.
  2. Al termine di questo processo, inclusi l'inserimento di dati e l'approvazione dai responsabili delle versioni, è possibile creare le pipeline di compilazione e versione successive per la fase di test. Queste fasi vengono create in un processo simile a quello descritto nel primo passaggio. Per la fase di test , potrebbero essere necessari altri test automatizzati o manuali dopo la distribuzione, per verificare che le modifiche siano pronte per essere rilasciate alla fase prod .
  3. Al termine di tutti i test automatizzati e manuali, il responsabile delle versioni può approvare e avviare le pipeline di compilazione e rilascio nella fase Prod . Poiché la fase Prod ha in genere configurazioni diverse rispetto alle fasi di test/sviluppo , è importante testare anche le modifiche dopo la distribuzione. Inoltre, la distribuzione deve attivare qualsiasi più inserimento di dati, in base alla modifica, per ridurre al minimo la potenziale non disponibilità per i consumer.

Quando è consigliabile usare l'opzione 2?

  • Quando si vuole usare Git come singola origine di verità e l'origine di tutte le distribuzioni.
  • Quando il team segue il flusso di lavoro basato su Trunk come strategia di diramazione.
  • È necessario un ambiente di compilazione (con uno script personalizzato) per modificare gli attributi specifici dell'area di lavoro, ad esempio connectionId e lakehouseId, prima della distribuzione.
  • È necessaria una pipeline di versione (script personalizzato) per recuperare il contenuto degli elementi da Git e chiamare l'API dell'elemento di infrastruttura corrispondente per la creazione, l'aggiornamento o l'eliminazione di elementi dell'infrastruttura modificati.

Opzione 3 - Distribuire usando le pipeline di distribuzione di Fabric

Diagramma che mostra il flusso della distribuzione basata su Git usando le pipeline di distribuzione.

Con questa opzione, Git viene connesso solo fino alla fase 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. Anche se lo strumento stesso è interno a Fabric, gli sviluppatori possono usare le API delle pipeline di distribuzione per orchestrare la distribuzione come parte della pipeline di versione di Azure o un flusso di lavoro 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.

Dopo l'approvazione e l'unione della richiesta pull al ramo principale :

  1. Viene attivata una pipeline di compilazione che carica le modifiche alla fase di sviluppo usando le API Git di Fabric. Se necessario, la pipeline può attivare altre API per avviare operazioni/test post-distribuzione nella fase di sviluppo .
  2. Al termine della distribuzione dello sviluppo , viene avviata una pipeline di versione per distribuire le modifiche dalla fase di sviluppo alla fase di test . I test automatizzati e manuali devono essere eseguiti dopo la distribuzione, per assicurarsi che le modifiche siano ben testate prima di raggiungere la produzione.
  3. Dopo il completamento dei test e il responsabile del rilascio approva la distribuzione nella fase Prod , la versione di Prod viene avviata e completa la distribuzione.

Quando è consigliabile usare l'opzione 3?

  • 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)

Diagramma che mostra il flusso della distribuzione basata su Git per isv.

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 predefinita, è consigliabile avere un processo di sviluppo e test centralizzato che si suddivide in ogni cliente solo nella fase Prod .

Questa opzione è basata sull'opzione 2. Dopo l'approvazione e l'unione della richiesta pull a main :

  1. Viene attivata una pipeline di compilazione per avviare un nuovo ambiente di compilazione ed eseguire unit test per la fase di sviluppo . Al termine dei test, viene attivata una pipeline di versione . Questa pipeline può caricare il contenuto in un ambiente di compilazione, eseguire script per modificare alcune configurazioni, modificare la configurazione in fase di sviluppo e quindi usare le API di definizione dell'elemento di aggiornamento di Fabric per caricare i file nell'area di lavoro.
  2. Al termine di questo processo, inclusi l'inserimento di dati e l'approvazione dai responsabili delle versioni, le pipeline di compilazione e versione successive per la fase di test possono iniziare. Questo processo è simile a quello descritto nel primo passaggio. Per la fase di test , potrebbero essere necessari altri test automatizzati o manuali dopo la distribuzione, per verificare che le modifiche siano pronte per essere rilasciate in fase prod in alta qualità.
  3. Dopo aver superato tutti i test e aver completato il processo di approvazione, è possibile avviare la distribuzione ai clienti Prod . Ogni cliente ha una propria versione con i propri parametri, in modo che la configurazione e la connessione dati specifiche possano essere eseguite nell'area di lavoro del cliente pertinente. La modifica della configurazione può verificarsi tramite script in un ambiente di compilazione o usando le API dopo la distribuzione. Tutte le versioni possono verificarsi in parallelo perché non sono correlate né dipendenti l'una dall'altra.

Quando è consigliabile usare l'opzione 4?

  • Si tratta di un ISV che compila 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 più 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