Pubblicazione automatizzata per l'integrazione e il recapito continui (CI/CD)

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Suggerimento

Provare Data Factory in Microsoft Fabric, una soluzione di analisi completa per le aziende. Microsoft Fabric copre tutti gli elementi, dallo spostamento dei dati all'analisi scientifica dei dati, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Scopri come avviare gratuitamente una nuova versione di valutazione .

Nota

Synapse Analytics supporta anche CI/CD. Per altre informazioni, vedere la documentazione ci/cd di Synapse Analytics.

Panoramica

L'integrazione continua è la procedura che consente di testare ogni modifica apportata alla base di codici automaticamente. Il recapito continuo, il prima possibile, segue i test che si verificano durante l'integrazione continua e inserisce le modifiche in un sistema di gestione temporanea o di produzione.

In Azure Data Factory, CI/CD significa spostare le pipeline di Data Factory da un ambiente, ad esempio sviluppo, test e produzione, a un altro. Data Factory usa modelli di Azure Resource Manager (modelli arm) per archiviare la configurazione delle varie entità di Data Factory, ad esempio pipeline, set di dati e flussi di dati.

Per alzare di livello una data factory a un altro ambiente, esistono due metodi consigliati:

  • Distribuzione automatizzata con l'integrazione di Data Factory con Azure Pipelines.
  • Caricare manualmente un modello di Resource Manager usando l'integrazione dell'esperienza utente di Data Factory con Azure Resource Manager.

Per altre informazioni, vedere Integrazione e recapito continui in Azure Data Factory.

Questo articolo è incentrato sui miglioramenti della distribuzione continua e sulla funzionalità di pubblicazione automatizzata per CI/CD.

Miglioramenti della distribuzione continua

La funzionalità di pubblicazione automatizzata accetta le funzionalità di convalida di tutti i modelli arm ed Esporta arm dall'esperienza utente di Data Factory e rende la logica utilizzabile tramite un pacchetto npm disponibile pubblicamente @microsoft/azure-data-factory-utilities. Per questo motivo, è possibile attivare queste azioni a livello di codice anziché passare all'interfaccia utente di Data Factory e selezionare un pulsante manualmente. Questa funzionalità offrirà alle pipeline CI/CD un'esperienza di integrazione continua più reale.

Nota

Assicurarsi di usare la versione del nodo 18.x e la versione compatibile per evitare errori che possono verificarsi a causa dell'incompatibilità del pacchetto con le versioni precedenti.

Flusso CI/CD corrente

  1. Ogni utente apporta modifiche nei rami privati.
  2. Il push al master non è consentito. Gli utenti devono creare una richiesta pull per apportare modifiche.
  3. Gli utenti devono caricare l'interfaccia utente di Data Factory e selezionare Pubblica per distribuire le modifiche in Data Factory e generare i modelli di Resource Manager nel ramo di pubblicazione.
  4. La pipeline devOps Release è configurata per creare una nuova versione e distribuire il modello di Resource Manager ogni volta che viene eseguito il push di una nuova modifica nel ramo di pubblicazione.

Diagram that shows the current CI/CD flow.

Passaggio manuale

Nel flusso CI/CD corrente, l'esperienza utente è l'intermediario per creare il modello di Resource Manager. Di conseguenza, un utente deve passare all'interfaccia utente di Data Factory e selezionare manualmente Pubblica per avviare la generazione del modello di Resource Manager e rilasciarlo nel ramo di pubblicazione.

Nuovo flusso CI/CD

  1. Ogni utente apporta modifiche nei rami privati.
  2. Il push al master non è consentito. Gli utenti devono creare una richiesta pull per apportare modifiche.
  3. La compilazione della pipeline di Azure DevOps viene attivata ogni volta che viene eseguito un nuovo commit nel master. Convalida le risorse e genera un modello di Resource Manager come artefatto se la convalida ha esito positivo.
  4. La pipeline devOps Release è configurata per creare una nuova versione e distribuire il modello di Resource Manager ogni volta che è disponibile una nuova compilazione.

Diagram that shows the new CI/CD flow.

Cosa è cambiato?

  • È ora disponibile un processo di compilazione che usa una pipeline di compilazione DevOps.
  • La pipeline di compilazione usa il pacchetto NPM ADFUtilities, che convaliderà tutte le risorse e genererà i modelli di Resource Manager. Questi modelli possono essere singoli e collegati.
  • La pipeline di compilazione è responsabile della convalida delle risorse di Data Factory e della generazione del modello di Resource Manager anziché dell'interfaccia utente di Data Factory (pulsante Pubblica ).
  • La definizione di versione devOps utilizzerà ora questa nuova pipeline di compilazione anziché l'artefatto Git.

Nota

È possibile continuare a usare il meccanismo esistente, ovvero il adf_publish ramo, oppure è possibile usare il nuovo flusso. Entrambi sono supportati.

Panoramica del pacchetto

Nel pacchetto sono attualmente disponibili due comandi:

  • Esportare un modello di Azure Resource Manager
  • Convalida

Esportare un modello di Azure Resource Manager

Eseguire npm run build export <rootFolder> <factoryId> [outputFolder] per esportare il modello di Resource Manager usando le risorse di una determinata cartella. Questo comando esegue anche un controllo di convalida prima di generare il modello di Resource Manager. Ecco un esempio che usa un gruppo di risorse denominato testResourceGroup:

npm run build export C:\DataFactories\DevDataFactory /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.DataFactory/factories/DevDataFactory ArmTemplateOutput
  • RootFolder è un campo obbligatorio che rappresenta la posizione in cui si trovano le risorse di Data Factory.
  • FactoryId è un campo obbligatorio che rappresenta l'ID risorsa di Data Factory nel formato /subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.DataFactory/factories/<dfName>.
  • OutputFolder è un parametro facoltativo che specifica il percorso relativo per salvare il modello di Resource Manager generato.

La possibilità di arrestare/avviare solo i trigger aggiornati è ora disponibile a livello generale e viene unita al comando illustrato in precedenza.

Nota

Il modello di Resource Manager generato non viene pubblicato nella versione dinamica della factory. La distribuzione deve essere eseguita usando una pipeline CI/CD.

Convalida

Eseguire npm run build validate <rootFolder> <factoryId> per convalidare tutte le risorse di una determinata cartella. Ecco un esempio:

npm run build validate C:\DataFactories\DevDataFactory /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.DataFactory/factories/DevDataFactory
  • RootFolder è un campo obbligatorio che rappresenta la posizione in cui si trovano le risorse di Data Factory.
  • FactoryId è un campo obbligatorio che rappresenta l'ID risorsa di Data Factory nel formato /subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.DataFactory/factories/<dfName>.

Creare una pipeline di Azure

Anche se i pacchetti npm possono essere usati in diversi modi, uno dei vantaggi principali viene usato tramite Azure Pipeline. In ogni unione nel ramo di collaborazione è possibile attivare una pipeline che convalida prima tutto il codice e quindi esporta il modello di Resource Manager in un artefatto di compilazione che può essere utilizzato da una pipeline di versione. Il modo in cui differisce dal processo CI/CD corrente è che si punterà la pipeline di versione a questo artefatto anziché al ramo esistenteadf_publish.

Per iniziare, segui questa procedura:

  1. Aprire un progetto Azure DevOps e passare a Pipeline. Selezionare Nuova pipeline.

    Screenshot that shows the New pipeline button.

  2. Selezionare il repository in cui si vuole salvare lo script YAML della pipeline. È consigliabile salvarlo in una cartella di compilazione nello stesso repository delle risorse di Data Factory. Verificare che nel repository sia presente un file package.json che contiene il nome del pacchetto, come illustrato nell'esempio seguente:

    {
        "scripts":{
            "build":"node node_modules/@microsoft/azure-data-factory-utilities/lib/index"
        },
        "dependencies":{
            "@microsoft/azure-data-factory-utilities":"^1.0.0"
        }
    } 
    
  3. Selezionare Pipeline starter. Se il file YAML è stato caricato o unito, come illustrato nell'esempio seguente, è anche possibile puntare direttamente a tale file e modificarlo.

    Screenshot that shows Starter pipeline.

    # Sample YAML file to validate and export an ARM template into a build artifact
    # Requires a package.json file located in the target repository
    
    trigger:
    - main #collaboration branch
    
    pool:
      vmImage: 'ubuntu-latest'
    
    steps:
    
    # Installs Node and the npm packages saved in your package.json file in the build
    
    - task: UseNode@1
      inputs:
        version: '18.x'
      displayName: 'Install Node.js'
    
    - task: Npm@1
      inputs:
        command: 'install'
        workingDir: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>' #replace with the package.json folder
        verbose: true
      displayName: 'Install npm package'
    
    # Validates all of the Data Factory resources in the repository. You'll get the same validation errors as when "Validate All" is selected.
    # Enter the appropriate subscription and name for the source factory. Either of the "Validate" or "Validate and Generate ARM temmplate" options are required to perform validation. Running both is unnecessary.
    
    - task: Npm@1
      inputs:
        command: 'custom'
        workingDir: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>' #replace with the package.json folder
        customCommand: 'run build validate $(Build.Repository.LocalPath)/<Root-folder-from-Git-configuration-settings-in-ADF> /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<Your-ResourceGroup-Name>/providers/Microsoft.DataFactory/factories/<Your-Factory-Name>'
      displayName: 'Validate'
    
    # Validate and then generate the ARM template into the destination folder, which is the same as selecting "Publish" from the UX.
    # The ARM template generated isn't published to the live version of the factory. Deployment should be done by using a CI/CD pipeline. 
    
    - task: Npm@1
      inputs:
        command: 'custom'
        workingDir: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>' #replace with the package.json folder
        customCommand: 'run build export $(Build.Repository.LocalPath)/<Root-folder-from-Git-configuration-settings-in-ADF> /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<Your-ResourceGroup-Name>/providers/Microsoft.DataFactory/factories/<Your-Factory-Name> "ArmTemplate"'
    #For using preview that allows you to only stop/ start triggers that are modified, please comment out the above line and uncomment the below line. Make sure the package.json contains the build-preview command. 
     #customCommand: 'run build-preview export $(Build.Repository.LocalPath) /subscriptions/222f1459-6ebd-4896-82ab-652d5f6883cf/resourceGroups/GartnerMQ2021/providers/Microsoft.DataFactory/factories/Dev-GartnerMQ2021-DataFactory "ArmTemplate"'
      displayName: 'Validate and Generate ARM template'
    
    # Publish the artifact to be used as a source for a release pipeline.
    
    - task: PublishPipelineArtifact@1
      inputs:
        targetPath: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>/ArmTemplate' #replace with the package.json folder
        artifact: 'ArmTemplates'
        publishLocation: 'pipeline'
    
  4. Immettere il codice YAML. È consigliabile usare il file YAML come punto di partenza.

  5. Salvare ed eseguire. Se è stato usato yaml, viene attivato ogni volta che il ramo principale viene aggiornato.

Nota

Gli artefatti generati contengono già script di pre e post-distribuzione per i trigger, quindi non è necessario aggiungerli manualmente. Tuttavia, quando si esegue la distribuzione, è comunque necessario fare riferimento alla documentazione sull'arresto e l'avvio dei trigger per eseguire lo script fornito.

Altre informazioni sull'integrazione e il recapito continui in Data Factory: integrazione e recapito continui in Azure Data Factory.