Zautomatyzowane publikowanie w ramach ciągłej integracji i ciągłego wdrażania (CI/CD)

DOTYCZY: Azure Data Factory Azure Synapse Analytics

Wskazówka

Data Factory w usłudze Microsoft Fabric jest następną generacją Azure Data Factory z prostszą architekturą, wbudowaną sztuczną inteligencją i nowymi funkcjami. Jeśli dopiero zaczynasz integrować dane, zacznij od Fabric Data Factory. Istniejące obciążenia ADF można zaktualizować do Fabric, aby uzyskać dostęp do nowych możliwości w zakresie nauki o danych, analiz w czasie rzeczywistym oraz raportowania.

Uwaga

Usługa Synapse Analytics obsługuje również ciągłą integrację/ciągłe wdrażanie. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją CI/CD usługi Synapse Analytics.

Omówienie

Ciągła integracja to metoda automatycznego testowania każdej zmiany wprowadzonej w bazie kodu. Ciągłe dostarczanie następuje jak najszybciej po testach wykonywanych podczas ciągłej integracji i wprowadza zmiany do systemu przejściowego lub produkcyjnego.

W Azure Data Factory ciągła integracja/ciągłe wdrażanie oznacza przenoszenie potoków usługi Data Factory z jednego środowiska, takiego jak programowanie, testowanie i produkcja, na inne. Usługa Data Factory używa szablonów Azure Resource Manager (ARM templates) do przechowywania konfiguracji różnych elementów usługi Data Factory, takich jak potoki, zestawy danych i przepływy danych.

Istnieją dwie sugerowane metody przeniesienia Data Factory do innego środowiska:

  • Automatyczne wdrożenie poprzez integrację Data Factory z Azure Pipelines.
  • Ręczne przekazywanie szablonu ARM przy użyciu integracji interfejsu użytkownika Data Factory z Azure Resource Manager.

Aby uzyskać więcej informacji, zobacz Continuous integration and delivery in Azure Data Factory (Integracja i dostarczanie w Azure Data Factory.

Ten artykuł koncentruje się na ulepszeniach w ciągłym wdrażaniu oraz funkcji automatycznego publikowania w ramach CI/CD.

Ulepszenia ciągłego wdrażania

Funkcja automatycznego publikowania korzysta z funkcji Zweryfikuj wszystkie i Eksportuj szablon ARM z interfejsu użytkownika usługi Data Factory i umożliwia wykorzystanie logiki poprzez publicznie dostępny pakiet npm @microsoft/azure-data-factory-utilities. Z tego powodu można programowo wyzwolić te akcje zamiast przejść do interfejsu użytkownika usługi Data Factory i ręcznie wybrać przycisk. Ta funkcja zapewnia Twoim potokom CI/CD prawdziwsze, ciągłe integracyjne doświadczenie.

Uwaga

Pamiętaj, aby używać Node.js wersji 20.x oraz jej kompatybilnej wersji, aby uniknąć błędów wynikających z niezgodności pakietów ze starszymi wersjami.

Bieżący przepływ CI/CD

  1. Każdy użytkownik wprowadza zmiany w swoich gałęziach prywatnych.
  2. Pushowanie na main nie jest dozwolone. Aby wprowadzić zmiany, użytkownicy muszą utworzyć pull request.
  3. Użytkownicy muszą załadować interfejs użytkownika usługi Data Factory i wybrać pozycję Publikuj , aby wdrożyć zmiany w usłudze Data Factory i wygenerować szablony usługi ARM w gałęzi publikowania.
  4. Potok wydań DevOps jest skonfigurowany do tworzenia nowej wersji i wdrażania szablonu ARM za każdym razem, gdy nowa zmiana zostanie wypchnięta do gałęzi publikacyjnej.

Diagram przedstawiający bieżący przepływ CI/CD.

Krok ręczny

W bieżącym przepływie ciągłej integracji/ciągłego wdrażania doświadczenie użytkownika jest pośrednikiem w tworzeniu szablonu ARM. W związku z tym użytkownik musi przejść do interfejsu Data Factory i ręcznie wybrać opcję Publikuj, aby uruchomić generowanie szablonu ARM i umieścić go w gałęzi publikowania.

Nowy proces CI/CD

  1. Każdy użytkownik wprowadza zmiany w swoich gałęziach prywatnych.
  2. Pushowanie na main nie jest dozwolone. Aby wprowadzić zmiany, użytkownicy muszą utworzyć pull request.
  3. Build pipeline Azure DevOps jest uruchamiany za każdym razem, gdy nowy commit zostanie utworzony do main. Weryfikuje zasoby i generuje szablon usługi ARM jako artefakt, jeśli walidacja zakończy się pomyślnie.
  4. Potok wydania metodyki DevOps jest skonfigurowany do tworzenia nowej wersji i wdrażania szablonu usługi ARM za każdym razem, gdy jest dostępna nowa kompilacja.

Diagram pokazujący nowy przepływ CI/CD.

Co się zmieniło?

  • Teraz masz proces budowania wykorzystujący pipeline DevOps.
  • Potok budowania wykorzystuje pakiet ADFUtilities (@microsoft/azure-data-factory-utilities) npm, który waliduje wszystkie zasoby i generuje szablony ARM. Te szablony mogą być pojedyncze i połączone.
  • Potok budowania weryfikuje zasoby Data Factory i generuje szablon ARM zamiast interfejsu Data Factory (przycisk Publish ).
  • Definicja wydania DevOps teraz zużywa ten nowy pipeline build zamiast artefaktu Gita.

Uwaga

Możesz nadal używać istniejącego mechanizmu, który jest gałęzią adf_publish , lub użyć nowego przepływu. Oba są obsługiwane.

Przegląd pakietu

W pakiecie są obecnie dostępne dwa polecenia:

  • Eksportowanie szablonu ARM
  • Sprawdź poprawność

Eksportowanie szablonu ARM

Uruchom polecenie npm run build export <rootFolder> <factoryId> [outputFolder] , aby wyeksportować szablon usługi ARM przy użyciu zasobów danego folderu. To polecenie wykonuje również weryfikację przed wygenerowaniem szablonu ARM. Oto przykład, który wykorzystuje grupę zasobów o nazwie testResourceGroup:

npm run build export C:\DataFactories\DevDataFactory /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.DataFactory/factories/DevDataFactory ArmTemplateOutput
  • RootFolder to obowiązkowe pole reprezentujące miejsce, w którym znajdują się zasoby usługi Data Factory.
  • FactoryId jest obowiązkowym polem reprezentującym identyfikator zasobu usługi Data Factory w formacie /subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.DataFactory/factories/<dfName>.
  • OutputFolder jest opcjonalnym parametrem określającym ścieżkę względną do zapisania wygenerowanego szablonu ARM.

Obecnie dostępna jest możliwość zatrzymania/uruchamiania tylko zaktualizowanych wyzwalaczy, która jest zintegrowana z poprzednim poleceniem.

Uwaga

Wygenerowany szablon ARM nie jest publikowany w wersji operacyjnej fabryki. Wdrożenie powinno odbywać się przy użyciu pipeline'u CI/CD.

Sprawdź poprawność

Uruchom polecenie npm run build validate <rootFolder> <factoryId> , aby zweryfikować wszystkie zasoby danego folderu. Oto przykład:

npm run build validate C:\DataFactories\DevDataFactory /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.DataFactory/factories/DevDataFactory
  • RootFolder to obowiązkowe pole reprezentujące miejsce, w którym znajdują się zasoby usługi Data Factory.
  • FactoryId jest obowiązkowym polem reprezentującym identyfikator zasobu usługi Data Factory w formacie /subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.DataFactory/factories/<dfName>.

Utwórz potok Azure

Chociaż pakiety npm można zużywać na różne sposoby, jedną z głównych zalet jest korzystanie z usług Azure Pipelines. Przy każdym połączeniu z gałęzią współpracy można uruchomić pipeline, który najpierw waliduje cały kod, a następnie eksportuje szablon ARM do artefaktu budowania , który może być wykorzystany przez pipeline release. Różni się to od obecnego procesu CI/CD tak, że kierujesz swój potok wydawniczy na ten artefakt zamiast na istniejącą adf_publish gałąź.

Wkonaj następujące kroki, aby rozpocząć:

  1. Otwórz projekt Azure DevOps i przejdź do Pipelines. Wybierz Nowy Przepływ.

    Zrzut ekranu przedstawiający przycisk Nowy pipeline.

  2. Wybierz repozytorium, w którym chcesz zapisać skrypt potoku YAML. Zapisz go w folderze build w tym samym repozytorium co zasoby Data Factory. Upewnij się, że w repozytorium znajduje się plik package.json zawierający nazwę pakietu, jak pokazano w poniższym przykładzie:

    {
        "scripts":{
            "build":"node node_modules/@microsoft/azure-data-factory-utilities/lib/index"
        },
        "dependencies":{
            "@microsoft/azure-data-factory-utilities":"^1.0.0"
        }
    } 
    
  3. Wybierz Potok startowy. Jeśli przekazałeś lub scaliłeś plik YAML, jak pokazano w poniższym przykładzie, możesz także bezpośrednio na niego wskazać i go edytować.

    Zrzut ekranu przedstawiający potok startowy.

    # 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. Wprowadź kod YAML. Użyj pliku YAML jako punktu wyjścia.

  5. Zapisz i uruchom. Jeśli użyto kodu YAML, zostanie ono wyzwolone za każdym razem, gdy gałąź główna zostanie zaktualizowana. Potwierdź, że przebieg się powiódł i wygenerował ArmTemplates artefakt z opublikowanych w pipeline.

Uwaga

Wygenerowane artefakty już zawierają skrypty przed i po wdrożeniu dla wyzwalaczy, więc nie musisz ich dodawać ręcznie. Jednak podczas wdrażania nadal musisz odwołać się do dokumentacji dotyczącej zatrzymania i uruchamiania wyzwalaczy , aby uruchomić dostarczony skrypt.

Dowiedz się więcej o ciągłej integracji i dostarczaniu w Data Factory: Ciągła integracja i dostarczanie w Azure Data Factory.