Ciągła integracja i dostarczanie w usłudze Azure Data Factory

  • Artykuł

DOTYCZY: Azure Data Factory Azure Synapse Analytics

Napiwek

Wypróbuj usługę Data Factory w usłudze Microsoft Fabric — rozwiązanie analityczne typu all-in-one dla przedsiębiorstw. Usługa Microsoft Fabric obejmuje wszystko, od przenoszenia danych do nauki o danych, analizy w czasie rzeczywistym, analizy biznesowej i raportowania. Dowiedz się, jak bezpłatnie rozpocząć nową wersję próbną !

Ciągła integracja to praktyka testowania każdej zmiany wprowadzonej w bazie kodu automatycznie i jak najszybciej. Ciągłe dostarczanie odbywa się po testowaniu, które jest wykonywane podczas ciągłej integracji, i wypycha zmiany do systemu przejściowego lub produkcyjnego.

W usłudze Azure Data Factory ciągła integracja i ciągłe dostarczanie (CI/CD) oznacza przenoszenie potoków usługi Data Factory z jednego środowiska (programistycznego, testowego, produkcyjnego) do innego. Usługa Azure Data Factory używa szablonów usługi Azure Resource Manager do przechowywania konfiguracji różnych jednostek usługi ADF (potoków, zestawów danych, przepływów danych itd.). Istnieją dwie sugerowane metody podwyższania poziomu fabryki danych do innego środowiska:

  • Automatyczne wdrażanie przy użyciu integracji usługi Data Factory z usługą Azure Pipelines
  • Ręczne przekazywanie szablonu usługi Resource Manager przy użyciu integracji środowiska użytkownika usługi Data Factory z usługą Azure Resource Manager.

Uwaga

Do interakcji z platformą Azure zalecamy używanie modułu Azure Az w programie PowerShell. Zobacz Instalowanie programu Azure PowerShell, aby rozpocząć. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.

Cykl życia ciągłej integracji/ciągłego wdrażania

Uwaga

Aby uzyskać więcej informacji, zobacz Ciągłe ulepszenia wdrażania.

Poniżej przedstawiono przykładowy przegląd cyklu życia ciągłej integracji/ciągłego wdrażania w fabryce danych Platformy Azure skonfigurowanej przy użyciu usługi Azure Repos Git. Aby uzyskać więcej informacji na temat konfigurowania repozytorium Git, zobacz Kontrola źródła w usłudze Azure Data Factory.

  1. Utworzono i skonfigurowano fabrykę danych deweloperskich za pomocą usługi Azure Repos Git. Wszyscy deweloperzy powinni mieć uprawnienia do tworzenia zasobów usługi Data Factory, takich jak potoki i zestawy danych.

  2. Deweloper tworzy gałąź funkcji, aby wprowadzić zmianę. Debugują przebiegi potoku przy użyciu najnowszych zmian. Aby uzyskać więcej informacji na temat debugowania przebiegu potoku, zobacz Iteracyjne programowanie i debugowanie za pomocą usługi Azure Data Factory.

  3. Gdy deweloper jest zadowolony ze swoich zmian, tworzy żądanie ściągnięcia z gałęzi funkcji do gałęzi głównej lub głównej, aby uzyskać zmiany przeglądane przez elementy równorzędne.

  4. Po zatwierdzeniu żądania ściągnięcia i scaleniu zmian w gałęzi głównej zmiany zostaną opublikowane w fabryce programowania.

  5. Gdy zespół jest gotowy do wdrożenia zmian w fabryce testowania testowego lub UAT (User Acceptance Testing), zespół przechodzi do wydania usługi Azure Pipelines i wdraża żądaną wersję fabryki deweloperów w usłudze UAT. To wdrożenie odbywa się w ramach zadania usługi Azure Pipelines i używa parametrów szablonu usługi Resource Manager do zastosowania odpowiedniej konfiguracji.

  6. Po zweryfikowaniu zmian w fabryce testowej wdróż w fabryce produkcyjnej przy użyciu następnego zadania wydania potoków.

Uwaga

Tylko fabryka deweloperów jest skojarzona z repozytorium git. Fabryki testowe i produkcyjne nie powinny mieć skojarzonego z nimi repozytorium git i powinny być aktualizowane tylko za pośrednictwem potoku usługi Azure DevOps lub szablonu zarządzania zasobami.

Na poniższej ilustracji przedstawiono różne kroki tego cyklu życia.

Diagram of continuous integration with Azure Pipelines

Najlepsze rozwiązania dotyczące ciągłej integracji/ciągłego wdrażania

Jeśli korzystasz z integracji usługi Git z fabryką danych i masz potok ciągłej integracji/ciągłego wdrażania, który przenosi zmiany z programowania do testowania, a następnie do środowiska produkcyjnego, zalecamy następujące najlepsze rozwiązania:

  • Integracja z usługą Git. Skonfiguruj tylko twoją fabrykę danych deweloperskich przy użyciu integracji z usługą Git. Zmiany w środowisku testowym i produkcyjnym są wdrażane za pośrednictwem ciągłej integracji/ciągłego wdrażania i nie wymagają integracji z usługą Git.

  • Skrypt przed wdrożeniem i po wdrożeniu. Przed krokiem wdrażania usługi Resource Manager w ciągłej integracji/ciągłego wdrażania należy wykonać określone zadania, takie jak zatrzymywanie i ponowne uruchamianie wyzwalaczy oraz wykonywanie oczyszczania. Zalecamy używanie skryptów programu PowerShell przed i po zadaniu wdrożenia. Aby uzyskać więcej informacji, zobacz Aktualizowanie aktywnych wyzwalaczy. Zespół fabryki danych udostępnił skrypt do użycia w dolnej części tej strony.

    Uwaga

    Użyj prePostDeploymentScript.Ver2.ps1, jeśli chcesz wyłączyć/włączyć tylko zmodyfikowane wyzwalacze zamiast wyłączać wszystkie wyzwalacze/ włączone podczas ciągłej integracji/ciągłego wdrażania.

    Ostrzeżenie

    Pamiętaj, aby uruchomić skrypt za pomocą programu PowerShell Core w zadaniu ADO.

    Ostrzeżenie

    Jeśli nie używasz najnowszych wersji modułu Programu PowerShell i usługi Data Factory, podczas uruchamiania poleceń mogą wystąpić błędy deserializacji.

  • Środowiska Integration Runtime i udostępnianie. Środowiska Integration Runtime nie zmieniają się często i są podobne we wszystkich etapach ciągłej integracji/ciągłego wdrażania. Dlatego usługa Data Factory oczekuje, że masz taką samą nazwę, typ i podtyp środowiska Integration Runtime na wszystkich etapach ciągłej integracji/ciągłego wdrażania. Jeśli chcesz udostępnić środowiska Integration Runtime na wszystkich etapach, rozważ użycieternarnej fabryki tylko do przechowywania udostępnionych środowisk Integration Runtime. Możesz użyć tej udostępnionej fabryki we wszystkich środowiskach jako połączonego typu środowiska Integration Runtime.

    Uwaga

    Udostępnianie środowiska Integration Runtime jest dostępne tylko dla własnych środowisk Integration Runtime. Środowiska Azure-SSIS Integration Runtime nie obsługują udostępniania.

  • Wdrożenie zarządzanego prywatnego punktu końcowego. Jeśli prywatny punkt końcowy już istnieje w fabryce i próbujesz wdrożyć szablon usługi ARM zawierający prywatny punkt końcowy o tej samej nazwie, ale z zmodyfikowanymi właściwościami, wdrożenie zakończy się niepowodzeniem. Innymi słowy, można pomyślnie wdrożyć prywatny punkt końcowy, o ile ma on te same właściwości co ten, który już istnieje w fabryce. Jeśli jakakolwiek właściwość różni się między środowiskami, można ją zastąpić, parametryzując daną właściwość i podając odpowiednią wartość podczas wdrażania.

  • Usługa Key Vault. W przypadku korzystania z połączonych usług, których informacje o połączeniu są przechowywane w usłudze Azure Key Vault, zaleca się przechowywanie oddzielnych magazynów kluczy w różnych środowiskach. Można również skonfigurować oddzielne poziomy uprawnień dla każdego magazynu kluczy. Na przykład możesz nie chcieć, aby członkowie zespołu mieli uprawnienia do wpisów tajnych produkcyjnych. Jeśli zastosujesz tę metodę, zalecamy zachowanie tych samych nazw wpisów tajnych we wszystkich etapach. Jeśli zachowasz te same nazwy wpisów tajnych, nie musisz parametrować poszczególnych parametry połączenia w środowiskach ciągłej integracji/ciągłego wdrażania, ponieważ jedyną rzeczą, która zmienia się, jest nazwa magazynu kluczy, który jest oddzielnym parametrem.

  • Nazewnictwo zasobów. Ze względu na ograniczenia szablonu usługi ARM problemy z wdrażaniem mogą wystąpić, jeśli zasoby zawierają spacje w nazwie. Zespół usługi Azure Data Factory zaleca używanie znaków "_" lub "-" zamiast spacji dla zasobów. Na przykład "Pipeline_1" będzie preferowaną nazwą potoku 1.

  • Zmienianie repozytorium. Usługa ADF automatycznie zarządza zawartością repozytorium GIT. Zmiana lub dodanie ręcznie niepowiązanych plików lub folderu w dowolnym miejscu w folderze danych repozytorium Git usługi ADF może spowodować błędy ładowania zasobów. Na przykład obecność plików bak może spowodować błąd ciągłej integracji/ciągłego wdrażania usługi ADF, dlatego należy je usunąć, aby można było załadować usługę ADF.

  • Kontrolka ekspozycji i flagi funkcji. Podczas pracy w zespole istnieją wystąpienia, w których można scalić zmiany, ale nie chcesz, aby były uruchamiane w środowiskach z podwyższonym poziomem uprawnień, takich jak PROD i QA. Aby obsłużyć ten scenariusz, zespół usługi ADF zaleca koncepcję metodyki DevOps używania flag funkcji. W usłudze ADF można połączyć parametry globalne i działanie warunku if, aby ukryć zestawy logiki na podstawie tych flag środowiska.

    Aby dowiedzieć się, jak skonfigurować flagę funkcji, zobacz poniższy samouczek wideo:

Nieobsługiwane funkcje

  • Zgodnie z projektem usługa Data Factory nie zezwala na wybieranie zatwierdzeń ani selektywnego publikowania zasobów. Opublikowanie będzie zawierać wszystkie zmiany wprowadzone w fabryce danych.

    • Jednostki fabryki danych zależą od siebie. Na przykład wyzwalacze zależą od potoków, a potoki zależą od zestawów danych i innych potoków. Selektywne publikowanie podzestawu zasobów może prowadzić do nieoczekiwanych zachowań i błędów.
    • W rzadkich przypadkach, gdy potrzebujesz selektywnego publikowania, rozważ użycie poprawki. Aby uzyskać więcej informacji, zobacz Środowisko produkcyjne poprawek.

  • Zespół usługi Azure Data Factory nie zaleca przypisywania kontrolek RBAC platformy Azure do poszczególnych jednostek (potoków, zestawów danych itp.) w fabryce danych. Jeśli na przykład deweloper ma dostęp do potoku lub zestawu danych, powinien mieć dostęp do wszystkich potoków lub zestawów danych w fabryce danych. Jeśli uważasz, że musisz zaimplementować wiele ról platformy Azure w fabryce danych, zapoznaj się z wdrażaniem drugiej fabryki danych.

  • Nie można publikować z gałęzi prywatnych.

  • Obecnie nie można hostować projektów w usłudze Bitbucket.

  • Obecnie nie można eksportować i importować alertów i macierzy jako parametrów.

  • W repozytorium kodu w gałęzi adf_publish folder o nazwie "PartialArmTemplates" jest obecnie dodawany obok folderu "linkedTemplates", "ARMTemplateForFactory.json" i "ARMTemplateParametersForFactory.json" w ramach publikowania z kontrolą źródła.

    Diagram of 'PartialArmTemplates' folder.

    Nie będziemy już publikować "PartialArmTemplates" w gałęzi adf_publish od 1 do listopada 2021 r.

    Nie jest wymagana żadna akcja, chyba że używasz polecenia "PartialArmTemplates". W przeciwnym razie przełącz się do dowolnego obsługiwanego mechanizmu wdrożeń przy użyciu: "ARMTemplateForFactory.json" lub "linkedTemplates".

Powiązana zawartość