CI/CD per le pipeline in Data Factory in Microsoft Fabric
In Fabric Data Factory, l'integrazione continua e lo sviluppo continuo (CI/CD) automatizza l'integrazione, il test e la distribuzione delle modifiche al codice per garantire uno sviluppo efficiente e affidabile.
In Fabric sono attualmente supportate due funzionalità in collaborazione con il team di Application Lifecycle Management (ALM): Integrazione Git e pipeline di distribuzione. Queste funzionalità consentono agli utenti di importare/esportare le risorse dell'area di lavoro con singoli aggiornamenti.
La soluzione CI/CD di Fabric Data Factory devia dal modello di Azure Data Factory in cui è preferibile usare la metodologia di esportazione dei modelli arm per l'intera factory. Questo cambiamento di metodologia consente ai clienti di scegliere selettivamente quali pipeline aggiornare senza mettere in pausa l' intera factory. Sia l'integrazione Git (bring-your-own Git) che le pipeline di distribuzione (CI/CD predefinite) utilizzano l'idea di associare una singola area di lavoro a un singolo ambiente. È necessario eseguire il mapping di aree di lavoro diverse ai diversi ambienti, ad esempio sviluppo, test e produzione.
Perché gli sviluppatori usano CI/CD
CI/CD è una pratica che automatizza la distribuzione del software e risolve alcuni punti di dolore importanti:
- Problemi di integrazione manuale: senza CI/CD, l'integrazione manuale delle modifiche al codice può causare conflitti ed errori, rallentando lo sviluppo.
- Ritardi di sviluppo: le distribuzioni manuali richiedono molto tempo e sono soggette a errori, causando ritardi nella distribuzione di nuove funzionalità e aggiornamenti.
- Ambienti incoerenti: ambienti diversi (sviluppo, test e produzione) possono avere incoerenze, causando problemi difficili da eseguire durante il debug.
- Mancanza di visibilità: senza CI/CD, il rilevamento delle modifiche e la comprensione dello stato della codebase possono risultare difficili.
Informazioni sulle pipeline di distribuzione, GIT e CI/CD
CI/CD è costituito dall'integrazione continua e dalla distribuzione continua.
Integrazione continua (CI)
Gli sviluppatori eseguono spesso il commit in un ramo principale gestito da Git, attivando test e compilazioni automatizzati per l'integrazione. Git tiene traccia delle modifiche per abilitare il recupero automatico e il test dei nuovi commit.
Distribuzione continua (CD)
È incentrata sulla distribuzione di modifiche verificate agli sviluppi di produzione tramite fasi di distribuzione strutturate all'interno delle pipeline di distribuzione.
Integrazione git con le pipeline di Data Factory
Git è un sistema di controllo della versione che consente agli sviluppatori di tenere traccia delle modifiche nella codebase (o nelle definizioni di codice JSON, nel caso delle pipeline) e collaborare con altri utenti. Fornisce un repository centralizzato in cui vengono archiviate e gestite le modifiche al codice. Git è attualmente supportato in Fabric tramite GitHub o Azure DevOps. Esistono alcuni aspetti fondamentali del flusso di lavoro da comprendere quando si lavora con Git.
- Ramo principale: il ramo principale, talvolta denominato ramo master, contiene il codice pronto per la produzione.
- Rami di funzionalità: questi rami sono separati dal ramo principale e consentono lo sviluppo isolato senza modificare il ramo principale.
- Richieste pull: le richieste pull consentono agli utenti di proporre, esaminare e discutere le modifiche prima dell'integrazione.
- Unione: si verifica quando vengono approvate le modifiche. Git integra queste modifiche, aggiornando continuamente il progetto.
Pipeline di distribuzione per Git
Le pipeline di distribuzione sono strettamente integrate con Git. Quando uno sviluppatore esegue il push delle modifiche al codice nel repository Git, attiva la pipeline CI/CD. Questa integrazione garantisce che le modifiche al codice più recenti vengano sempre testate e distribuite automaticamente.
Fasi e processi
Le pipeline di distribuzione sono costituite da più fasi e processi all'interno di ogni fase. In genere, queste fasi sono separate in tre ambienti: sviluppo (codice di compilazione), test (esecuzione di test) e produzione (distribuzione dell'applicazione). La pipeline procede attraverso queste fasi, assicurandosi che il codice venga testato e distribuito accuratamente in modo controllato.
Flussi di lavoro automatizzati
Le pipeline di distribuzione automatizzano l'intero processo di compilazione, test e distribuzione del codice. Questa automazione riduce il rischio di errore umano, accelera il processo di sviluppo e garantisce che le modifiche al codice vengano distribuite in modo coerente e affidabile all'ambiente di produzione.
Introduzione all'integrazione git per le pipeline di Data Factory
Per configurare l'integrazione Git per le pipeline in Data Factory, seguire questa procedura:
Prerequisiti per l'integrazione di Git
Per accedere a Git con l'area di lavoro di Microsoft Fabric, verificare i prerequisiti seguenti per Fabric e Git.
- Una licenza di Power BI Premium o una capacità dell'infrastruttura.
- Abilitato il tenant seguente passa dal portale di amministrazione:
- Un account Azure DevOps o GitHub.
- Per un account Azure DevOps:
- Un account Azure attivo registrato con lo stesso utente che usa l'area di lavoro Infrastruttura. Creare un account gratuito.
- Accesso a un repository esistente
- Per un account GitHub:
- Un account GitHub attivo. Creare un account gratuito.
- Un token con granularità fine con autorizzazioni di lettura e scrittura per Contenuto, in autorizzazioni del repository o un token di GitHub classico con ambiti di repository abilitati.
- Per un account Azure DevOps:
Passaggio 1: Connettersi a un repository Git
Per usare l'integrazione Git con le pipeline di Data Factory in Fabric, è prima necessario connettersi a un repository Git, come descritto qui.
Accedere a Fabric e passare all'area di lavoro che si vuole connettere a Git.
Selezionare Impostazioni area di lavoro.
Selezionare Integrazione con Git.
Selezionare il provider Git. Attualmente Fabric supporta solo Azure DevOps o GitHub. Se si usa GitHub, è necessario selezionare Aggiungi account per connettere l'account GitHub. Dopo aver eseguito l'accesso, selezionare Connetti per consentire a Fabric di accedere all'account GitHub.
Passaggio 2: Connettersi a un'area di lavoro
Dopo aver eseguito la connessione a un repository Git, è necessario connettersi a un'area di lavoro, come descritto qui.
Dal menu a discesa specificare i dettagli seguenti sul ramo a cui ci si vuole connettere:
Per le connessioni del ramo Azure DevOps, specificare i dettagli seguenti:
- Organizzazione: nome dell'organizzazione di Azure DevOps.
- Progetto: nome del progetto Azure DevOps.
- Repository: nome del repository Di Azure DevOps.
- Branch: il nome del ramo di Azure DevOps.
- Cartella: nome della cartella Azure DevOps.
Per le connessioni al ramo GitHub, specificare i dettagli seguenti:
- URL repository: URL del repository GitHub.
- Branch: nome del ramo GitHub.
- Cartella: nome della cartella GitHub.
Selezionare Connettersi e sincronizzare.
Dopo la connessione, l'area di lavoro visualizza informazioni sul controllo del codice sorgente che consente agli utenti di visualizzare il ramo connesso, lo stato di ogni elemento nel ramo e l'ora dell'ultima sincronizzazione.
Passaggio 3: Eseguire il commit delle modifiche in Git
Dopo la connessione a un repository Git e a un'area di lavoro, è possibile eseguire il commit delle modifiche in Git, come descritto qui.
Passare all'area di lavoro.
Selezionare l'icona Controllo del codice sorgente. Questa icona mostra il numero di modifiche non sottoposte a commit.
Selezionare la scheda Modifiche nel pannello di controllo Origine. Viene visualizzato un elenco con tutti gli elementi modificati e un'icona che indica lo stato: Nuovo
, Modificato
, Conflitto
o Eliminato.
Selezionare gli elementi su cui eseguire il commit. Spuntare la casella superiore per selezionare tutti gli elementi.
(Facoltativo) Aggiungere un commento di commit nella casella.
Selezionare Commit.
Dopo il commit delle modifiche, gli elementi di cui è stato eseguito il commit vengono rimossi dall'elenco e l'area di lavoro farà riferimento al nuovo commit sincronizzato.
Passaggio 4: (Facoltativo) Aggiornare l'area di lavoro da Git
Passare all'area di lavoro.
Selezionare l'icona Controllo del codice sorgente.
Selezionare Aggiornamenti nel pannello di controllo Del codice sorgente. Viene visualizzato un elenco con tutti gli elementi modificati nel ramo dall'origine della connessione Git dall'ultimo aggiornamento.
Selezionare Aggiorna tutto.
Dopo l'aggiornamento, l'elenco degli elementi viene rimosso e l'area di lavoro punterà al nuovo commit a cui è sincronizzato.
Introduzione alle pipeline di distribuzione per Git
Seguire questa procedura per usare le pipeline di distribuzione Git con l'area di lavoro Infrastruttura.
Prerequisiti per le pipeline di distribuzione
Prima di iniziare, assicurarsi di configurare i prerequisiti seguenti:
- Una sottoscrizione attiva di Microsoft Fabric.
- Accesso amministratore di un'area di lavoro infrastruttura.
Passaggio 1: Creare una pipeline di distribuzione
Nel riquadro a comparsa Aree di lavoro selezionare Pipeline di distribuzione.
Selezionare Crea pipeline o + Nuova pipeline.
Passaggio 2: Assegnare un nome alla pipeline e assegnare le fasi
Nella finestra di dialogo Crea una pipeline di distribuzione immettere un nome e una descrizione per la pipeline e selezionare Avanti.
Impostare la struttura della pipeline di distribuzione definendo le fasi necessarie per la pipeline di distribuzione. Per impostazione predefinita, la pipeline ha tre fasi: Sviluppo, Test e Produzione.
È possibile aggiungere un'altra fase, eliminare le fasi o rinominarle digitando un nuovo nome nella casella. Al termine, selezionare Crea (o Crea e continuare).
Passaggio 3: Assegnare un'area di lavoro alla pipeline di distribuzione
Dopo aver creato una pipeline, è necessario aggiungere contenuto da gestire alla pipeline. L'aggiunta di contenuto alla pipeline viene eseguita assegnando un'area di lavoro alla fase della pipeline. È possibile assegnare un'area di lavoro a qualsiasi fase. Seguire le istruzioni per Assegnare un'area di lavoro a una pipeline.
Passaggio 4: Eseguire la distribuzione in una fase vuota
Al termine dell'uso del contenuto in una fase della pipeline, è possibile distribuirlo alla fase successiva. Le pipeline di distribuzione offrono tre opzioni per la distribuzione dei contenuti:
- Distribuzione completa: distribuire tutto il contenuto nella fase di destinazione.
- Distribuzione selettiva: selezionare il contenuto da distribuire nella fase di destinazione.
- Distribuzione con le versioni precedenti: distribuire il contenuto da una fase successiva a una fase precedente nella pipeline. Attualmente, la distribuzione inversa è possibile solo quando la fase di destinazione è vuota (non è assegnata alcuna area di lavoro).
Dopo aver scelto come distribuire il contenuto, è possibile esaminare la distribuzione e lasciare una nota.
Passaggio 5: Distribuire il contenuto da una fase a un'altra
- Quando è presente contenuto in una fase della pipeline, è possibile distribuirlo alla fase successiva anche se l'area di lavoro della fase successiva ha del contenuto. Gli elementi associati vengono sovrascritti. Per altre informazioni su questo processo, vedere la sezione Distribuire contenuto in un'area di lavoro esistente.
- È possibile esaminare la cronologia della distribuzione per visualizzare l'ultima distribuzione del contenuto in ogni fase. Per esaminare le differenze tra le due pipeline prima della distribuzione, vedere Confrontare il contenuto in diverse fasi di distribuzione.
Limitazioni note
Le limitazioni note seguenti si applicano a CI/CD per le pipeline in Data Factory in Microsoft Fabric:
- Variabili dell'area di lavoro: CI/CD attualmente non supporta le variabili dell'area di lavoro.
- Supporto limitato per l'integrazione git: Attualmente Fabric supporta solo l'integrazione git con Azure DevOps e GitHub. L'integrazione git di Azure DevOps è consigliata perché l'integrazione git di GitHub presenta più limitazioni.
- Attività della pipeline con connettori OAuth: per i connettori MS Teams e Outlook, quando si esegue la distribuzione in un ambiente superiore, gli utenti devono aprire manualmente ogni pipeline e accedere a ogni attività, che è attualmente una limitazione.
- Pipeline che richiamano flussi di dati: quando una pipeline che richiama un flusso di dati viene alzata di livello, farà comunque riferimento al flusso di dati nell'area di lavoro precedente, che non è corretto. Questo comportamento si verifica perché i flussi di dati non sono attualmente supportati nelle pipeline di distribuzione.
Contenuto correlato
- Introduzione al processo CI/CD come parte del ciclo ALM in Microsoft Fabric
- Introduzione all'integrazione con Git, lo strumento Fabric Application Lifecycle Management (ALM)
- Introduzione all'uso delle pipeline di distribuzione, lo strumento Di gestione del ciclo di vita delle applicazioni di Infrastruttura
- Blog: Esplorazione delle funzionalità CI/CD in Microsoft Fabric: Focus sulle pipeline