Automatisiertes Veröffentlichen für kontinuierliche Integration und Bereitstellung (CI/CD)

Gilt für: Azure Data Factory Azure Synapse Analytics

Tipp

Data Factory in Microsoft Fabric ist die nächste Generation von Azure Data Factory mit einer einfacheren Architektur, integrierter KI und neuen Features. Wenn Sie mit der Datenintegration noch nicht vertraut sind, beginnen Sie mit Fabric Data Factory. Vorhandene ADF-Workloads können auf Fabric aktualisiert werden, um auf neue Funktionen in der Datenwissenschaft, Echtzeitanalysen und Berichterstellung zuzugreifen.

Hinweis

Synapse Analytics unterstützt auch CI/CD. Weitere Informationen finden Sie in der Synapse Analytics CI/CD-Dokumentation .

Übersicht

Bei Continuous Integration wird jede Änderung, die an Ihrer Codebasis vorgenommen wird, automatisch getestet. So früh wie möglich folgt die kontinuierliche Auslieferung auf das Testen, das während der kontinuierlichen Integration stattfindet, und überträgt Änderungen in ein Staging- oder Produktionssystem.

In Azure Data Factory bedeutet CI/CD das Verschieben von Data Factory-Pipelines aus einer Umgebung, z. B. Entwicklung, Test und Produktion, in eine andere. Data Factory verwendet Azure Resource Manager-Vorlagen (ARM-Vorlagen) um die Konfiguration Ihrer verschiedenen Data Factory-Entitäten wie Pipelines, Datasets und Datenflüsse zu speichern.

Es gibt zwei empfohlene Methoden zum Übertragen einer Data Factory auf eine andere Umgebung:

  • Automatisierte Bereitstellung durch die Integration von Data Factory mit Azure Pipelines.
  • Manuelles Hochladen einer ARM-Vorlage mithilfe der Integration der Data Factory-Benutzeroberfläche in Azure Resource Manager.

Weitere Informationen finden Sie unter Continuous integration and delivery in Azure Data Factory.

In diesem Artikel liegt der Fokus auf den Verbesserungen beim kontinuierlichen Deployment und der Funktion für die automatisierte Veröffentlichung im Rahmen von CI/CD.

Verbesserungen bei Continuous Deployment

Das Feature „Automatisierte Veröffentlichung“ integriert die Funktionen Alle überprüfen und ARM-Vorlage exportieren aus der Data Factory-Benutzeroberfläche und macht die Logik über das öffentlich verfügbare npm-Paket @microsoft/azure-data-factory-utilities nutzbar. Daher können Sie diese Aktionen programmgesteuert auslösen, anstatt zur Data Factory-Benutzeroberfläche zu wechseln und manuell eine Schaltfläche auszuwählen. Diese Fähigkeit bietet Ihren CI/CD-Pipelines ein realistischeres kontinuierliches Integrationserlebnis.

Hinweis

Achten Sie darauf, Node.js Version 20.x und deren kompatible Version zu verwenden, um Fehler zu vermeiden, die durch Paketinkompatibilität mit älteren Versionen auftreten können.

Aktueller CI/CD-Flow

  1. Alle Benutzer nehmen Änderungen in ihren privaten Branches vor.
  2. Push to Main ist nicht erlaubt. Benutzer müssen einen Pull Request erstellen, um Änderungen vorzunehmen.
  3. Benutzer müssen die Benutzeroberfläche von Data Factory laden und Veröffentlichen auswählen, um Änderungen an Data Factory bereitzustellen und die ARM-Vorlagen im Veröffentlichungszweig zu generieren.
  4. Die DevOps-Releasepipeline ist so konfiguriert, dass sie jedes Mal, wenn eine neue Änderung in den Veröffentlichungsbranch gepusht wird, ein neues Release erstellt und die ARM-Vorlage bereitstellt.

Diagramm mit dem aktuellen CI/CD-Flow

Manueller Schritt

Im aktuellen CI/CD-Flow ist die Benutzeroberfläche der Vermittler zum Erstellen der ARM-Vorlage. Folglich muss ein Benutzer die Data Factory-Benutzeroberfläche aufrufen und manuell Veröffentlichen auswählen, um die Generierung der ARM-Vorlage zu starten und sie in den Veröffentlichungsbranch einzufügen.

Der neue CI/CD-Flow

  1. Alle Benutzer nehmen Änderungen in ihren privaten Branches vor.
  2. Push to Main ist nicht erlaubt. Benutzer müssen einen Pull Request erstellen, um Änderungen vorzunehmen.
  3. Der Azure DevOps-Pipeline-Build wird jedes Mal ausgelöst, wenn ein neuer Commit auf das Hauptaccount gemacht wird. Die Ressourcen werden überprüft, und es wird eine ARM-Vorlage als Artefakt generiert, wenn die Überprüfung erfolgreich ist.
  4. Die DevOps-Releasepipeline ist so konfiguriert, dass sie jedes Mal ein neues Release erstellt und die ARM-Vorlage bereitstellt, wenn ein neuer Build verfügbar ist.

Diagramm mit dem neuen CI/CD-Flow

Was hat sich geändert?

  • Sie haben jetzt einen Build-Prozess, der eine DevOps-Build-Pipeline verwendet.
  • Die Build-Pipeline verwendet das npm-Paket ADFUtilities (@microsoft/azure-data-factory-utilities) npm, das alle Ressourcen validiert und die ARM-Vorlagen generiert. Dabei kann es sich um einzelne oder verknüpfte Vorlagen handeln.
  • Die Build-Pipeline validiert Data Factory-Ressourcen und generiert die ARM-Vorlage anstelle der Data Factory-Benutzeroberfläche (Veröffentlichen-Button ).
  • Die DevOps-Release-Definition verbraucht nun diese neue Build-Pipeline anstelle des Git-Artefakts.

Hinweis

Sie können weiterhin den vorhandenen Mechanismus, d. h. den adf_publish-Branch, oder den neuen Flow verwenden. Beide Verfahren werden unterstützt.

Paketübersicht

Im Paket sind zurzeit zwei Befehle verfügbar:

  • Exportieren einer ARM-Vorlage
  • Überprüfen

Exportieren einer ARM-Vorlage

Führen Sie npm run build export <rootFolder> <factoryId> [outputFolder] aus, um die ARM-Vorlage unter Verwendung der Ressourcen eines bestimmten Ordners zu exportieren. Dieser Befehl führt außerdem eine Validierungsprüfung durch, bevor die ARM-Vorlage generiert wird. Hier ist ein Beispiel, das eine Ressourcengruppe namens testResourceGroup verwendet:

npm run build export C:\DataFactories\DevDataFactory /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.DataFactory/factories/DevDataFactory ArmTemplateOutput
  • RootFolder ist ein obligatorisches Feld, das den Speicherort der Data Factory-Ressourcen darstellt.
  • FactoryId ist ein obligatorisches Feld, das die Data Factory-Ressourcen-ID im Format /subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.DataFactory/factories/<dfName> darstellt.
  • OutputFolder ist ein optionaler Parameter, der den relativen Pfad zum Speichern der generierten ARM-Vorlage angibt.

Die Möglichkeit, nur die aktualisierten Trigger zu stoppen/zu starten, ist nun allgemein verfügbar und wird in den vorherigen Befehl integriert.

Hinweis

Die generierte ARM-Vorlage wird nicht in der Liveversion der Factory veröffentlicht. Die Bereitstellung sollte mithilfe einer CI/CD-Pipeline erfolgen.

Überprüfen

Führen Sie npm run build validate <rootFolder> <factoryId> aus, um alle Ressourcen eines bestimmten Ordners zu überprüfen. Ein Beispiel:

npm run build validate C:\DataFactories\DevDataFactory /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.DataFactory/factories/DevDataFactory
  • RootFolder ist ein obligatorisches Feld, das den Speicherort der Data Factory-Ressourcen darstellt.
  • FactoryId ist ein obligatorisches Feld, das die Data Factory-Ressourcen-ID im Format /subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.DataFactory/factories/<dfName> darstellt.

Erstellen einer Azure Pipeline

Obwohl npm-Pakete auf verschiedene Weise konsumiert werden können, ist einer der Hauptvorteile, dass sie über Azure Pipelines genutzt werden. Bei jedem Merge in Ihren Kollaborationsbranch kann eine Pipeline ausgelöst werden, die zunächst den gesamten Code validiert und dann die ARM-Vorlage in ein Build-Artefakt exportiert, das von einer Release-Pipeline verbraucht werden kann. Der Unterschied zum aktuellen CI/CD-Prozess ist, dass du deine Release-Pipeline auf dieses Artefakt und nicht auf den bestehenden adf_publish Branch ausrichtest.

Gehen Sie dazu wie folgt vor:

  1. Öffnen Sie ein Azure DevOps Projekt, und wechseln Sie zu Pipelines. Wählen Sie Neue Pipeline aus.

    Screenshot der Schaltfläche „Neue Pipeline“

  2. Wählen Sie das Repository aus, in dem Sie das YAML-Skript Ihrer Pipeline speichern möchten. Speichere es in einem Build-Ordner im selben Repository wie deine Data Factory-Ressourcen. Stellen Sie sicher, dass im Repository die Datei package.json vorhanden ist, die den Paketnamen enthält, wie im folgenden Beispiel gezeigt:

    {
        "scripts":{
            "build":"node node_modules/@microsoft/azure-data-factory-utilities/lib/index"
        },
        "dependencies":{
            "@microsoft/azure-data-factory-utilities":"^1.0.0"
        }
    } 
    
  3. Wählen Sie Starterpipeline aus. Wenn Sie die YAML-Datei wie im Beispiel unten hochgeladen oder zusammengeführt haben, können Sie auch direkt darauf verweisen und sie bearbeiten.

    Screenshot der 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: '20.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 template" 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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. Geben Sie den YAML-Code ein. Nutze die YAML-Datei als Ausgangspunkt.

  5. Speichern und ausführen. Wenn Sie die YAML-Datei verwendet haben, wird diese jedes Mal ausgelöst, wenn der Mainbranch aktualisiert wird. Bestätigen Sie, dass der Lauf erfolgreich ist und das ArmTemplates Artefakt in den veröffentlichten Artefakten der Pipeline hervorbringt.

Hinweis

Die generierten Artefakte enthalten bereits Pre- und Post-Deployment-Skripte für die Trigger, sodass du sie nicht manuell hinzufügen musst. Wenn du jedoch deployest, musst du trotzdem die Dokumentation zum Stoppen und Starten von Triggern konsultieren, um das bereitgestellte Skript auszuführen.

Erfahren Sie mehr über kontinuierliche Integration und Bereitstellung in Data Factory: Kontinuierliche Integration und Bereitstellung in Azure Data Factory.