Automatisiertes Veröffentlichen für Continuous Integration und Delivery (CI/CD)

Artikel
04/09/2024

GILT FÜR: Azure Data Factory Azure Synapse Analytics

Tipp

Testen Sie Data Factory in Microsoft Fabric, eine All-in-One-Analyselösung für Unternehmen. Microsoft Fabric deckt alle Aufgaben ab, von der Datenverschiebung bis hin zu Data Science, Echtzeitanalysen, Business Intelligence und Berichterstellung. Erfahren Sie, wie Sie kostenlos eine neue Testversion starten!

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. Der Continuous Delivery-Prozess folgt so früh wie möglich auf das Testen während des Continuous Integration-Prozesses. Änderungen werden dabei in ein Staging- oder Produktionssystem gepusht.

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 ARM-Vorlagen (Azure Resource Manager) zum Speichern der Konfiguration Ihrer verschiedenen Data Factory-Entitäten wie Pipelines, Datasets und Datenflüsse.

Es gibt zwei empfohlene Methoden zum Höherstufen einer Data Factory in eine andere Umgebung:

Automatisierte Bereitstellung über die Integration von Data Factory in Azure Pipelines.
Manuelles Hochladen einer ARM-Vorlage über die Data Factory-Benutzeroberflächenintegration in Azure Resource Manager.

Weitere Informationen finden Sie unter Continuous Integration und Continuous Delivery in Azure Data Factory.

In diesem Artikel liegt der Fokus auf den Verbesserungen bei Continuous Deployment und auf dem Feature für die automatisierte Veröffentlichung für CI/CD.

Verbesserungen bei Continuous Deployment

Im Feature „Automatisierte Veröffentlichung“ sind die Funktionen Alle überprüfen und ARM-Vorlage exportieren von der Data Factory-Benutzeroberfläche zusammengefasst. Die Logik wird über das öffentlich verfügbare npm-Paket @microsoft/azure-data-factory-utilities bereitgestellt. Daher können Sie diese Aktionen programmgesteuert auslösen, anstatt zur Data Factory-Benutzeroberfläche zu wechseln und manuell eine Schaltfläche auszuwählen. Mithilfe dieser Möglichkeit werden Ihre CI/CD-Pipelines zu echten Continuous Integration-Prozessen.

Hinweis

Achten Sie darauf, dass Sie die Knotenversion 18.x und ihre kompatible Version verwenden, um Fehler zu vermeiden, die aufgrund der Paketinkompatibilität mit älteren Versionen auftreten können.

Aktueller CI/CD-Flow

Alle Benutzer nehmen Änderungen in ihren privaten Branches vor.
Push an Master ist nicht zulässig. Benutzer müssen einen Pull Request erstellen, um Änderungen vorzunehmen.
Benutzer müssen die Data Factory-Benutzeroberfläche laden und Veröffentlichen auswählen, um Änderungen an Data Factory bereitzustellen und die ARM-Vorlagen im Veröffentlichungsbranch zu generieren.
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.

Diagram that shows the current 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

Alle Benutzer nehmen Änderungen in ihren privaten Branches vor.
Push an Master ist nicht zulässig. Benutzer müssen einen Pull Request erstellen, um Änderungen vorzunehmen.
Der Buildvorgang der Azure DevOps-Pipeline wird bei jedem neuen Commit an den Masterbranch ausgeführt. Die Ressourcen werden überprüft, und es wird eine ARM-Vorlage als Artefakt generiert, wenn die Überprüfung erfolgreich ist.
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.

Diagram that shows the new CI/CD flow.

Was hat sich geändert?

Der neue Buildprozess verwendet eine DevOps-Buildpipeline.
Die Buildpipeline verwendet das npm-Paket „ADFUtilities“, das alle Ressourcen überprüft und die ARM-Vorlagen generiert. Dabei kann es sich um einzelne oder verknüpfte Vorlagen handeln.
Die Buildpipeline ist anstelle der Data Factory-Benutzeroberfläche (Schaltfläche Veröffentlichen) für das Überprüfen von Data Factory-Ressourcen und das Erstellen der ARM-Vorlage verantwortlich.
Die DevOps-Releasedefinition nutzt nun diese neue Buildpipeline 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. Mit diesem Befehl wird vor dem Generieren der ARM-Vorlage auch eine Überprüfung ausgeführt. Im folgenden Beispiel wird 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 Auslöser zu stoppen/starten, ist jetzt allgemein verfügbar und wurde in den oben gezeigten Befehl zusammengeführt.

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

npm-Pakete können zwar auf verschiedene Weise genutzt werden, aber einer der Hauptvorteile ist die Nutzung über Azure Pipelines. Bei jedem Merge in den Kollaborationsbranch kann eine Pipeline ausgelöst werden, die zuerst den gesamten Code überprüft und dann die ARM-Vorlage in ein Buildartefakt exportiert, das von einer Releasepipeline verwendet werden kann. Der Unterschied zum aktuellen CI/CD-Prozess besteht darin, dass Sie in der Releasepipeline nicht auf den vorhandenen adf_publish-Branch, sondern auf dieses Artefakt verweisen.

Gehen Sie dazu wie folgt vor:

Öffnen Sie ein Azure DevOps-Projekt, und navigieren Sie zu Pipelines. Wählen Sie Neue Pipeline aus.
Wählen Sie das Repository aus, in dem Sie das YAML-Skript Ihrer Pipeline speichern möchten. Es wird empfohlen, die Datei im Ordner „build“ im gleichen Repository wie Ihre Data Factory-Ressourcen zu speichern. 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"
    }
} 
```

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 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'

Geben Sie den YAML-Code ein. Es wird empfohlen, dass Sie die YAML-Datei als Ausgangspunkt verwenden.
Speichern Sie das Projekt, und führen Sie es aus. Wenn Sie die YAML-Datei verwendet haben, wird diese jedes Mal ausgelöst, wenn der Mainbranch aktualisiert wird.

Hinweis

Die generierten Artefakte enthalten bereits Skripts vor und nach der Bereitstellung für die Trigger, sodass es nicht erforderlich ist, diese manuell hinzuzufügen. Bei der Bereitstellung muss jedoch weiterhin auf die Dokumentation zum Beenden und Starten von Triggern verwiesen werden, um das bereitgestellte Skript auszuführen.

Erfahren Sie mehr über Continuous Integration und Continuous Delivery in Data Factory: Continuous Integration und Continuous Delivery in Azure Data Factory.

Freigeben über

Automatisiertes Veröffentlichen für Continuous Integration und Delivery (CI/CD)

Übersicht

Verbesserungen bei Continuous Deployment

Aktueller CI/CD-Flow

Manueller Schritt

Der neue CI/CD-Flow

Was hat sich geändert?

Paketübersicht

Exportieren einer ARM-Vorlage

Überprüfen

Erstellen einer Azure-Pipeline

Feedback

Zusätzliche Ressourcen

Freigeben über

Automatisiertes Veröffentlichen für Continuous Integration und Delivery (CI/CD)

Übersicht

Verbesserungen bei Continuous Deployment

Aktueller CI/CD-Flow

Manueller Schritt

Der neue CI/CD-Flow

Was hat sich geändert?

Paketübersicht

Exportieren einer ARM-Vorlage

Überprüfen

Erstellen einer Azure-Pipeline

Zugehöriger Inhalt

Feedback

Zusätzliche Ressourcen