Ciągła integracja i ciągłe dostarczanie w Azure Data Factory

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.

Ciągła integracja to praktyka testowania każdej zmiany wprowadzonej w bazie kodu automatycznie i jak najszybciej. Ciągłe dostarczanie następuje po testach realizowanych w ramach ciągłej integracji i wdraża zmiany do systemu przejściowego lub produkcyjnego.

W 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 (programowanie, testowanie, produkcja) do innego. Azure Data Factory używa szablonów Azure Resource Manager do przechowywania konfiguracji różnych jednostek Data Factory (na przykład potoków, zbiorów danych i przepływów danych). Istnieją dwie sugerowane metody przenoszenia fabryki danych do innego środowiska:

  • Automatyczne wdrożenie dzięki integracji Data Factory z Azure Pipelines
  • Ręcznie przekaż szablon Resource Manager za pomocą integracji interfejsu użytkownika usługi Data Factory z Azure Resource Manager.

Uwaga

Zalecamy użycie modułu Azure Az programu PowerShell do interakcji z Azure. Aby rozpocząć, zobacz Install Azure PowerShell. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az programu PowerShell, zobacz Migrate Azure PowerShell z modułu AzureRM do modułu Az.

Proces ciągłej integracji i dostarczania/deploymentu

Uwaga

Aby uzyskać więcej informacji, zobacz Ulepszenia ciągłego wdrażania.

Poniższy przegląd pokazuje cykl życia CI/CD w fabryce danych Azure skonfigurowanej z pomocą Azure Repos Git. Aby uzyskać więcej informacji na temat konfigurowania repozytorium Git, zobacz Kontrola źródła w Azure Data Factory.

  1. Utworzono i skonfigurowano fabrykę danych deweloperskich przy użyciu 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ę. Podpisane commity nie są wspierane w Data Factory. Debugują przebiegi potoku przy użyciu najnowszych zmian. Aby uzyskać więcej informacji na temat debugowania uruchomienia potoku, zobacz Iteracyjne programowanie i debugowanie przy użyciu Azure Data Factory.

  3. Gdy deweloper jest zadowolony ze swoich zmian, tworzy żądanie połączenia z gałęzi funkcji do gałęzi głównej lub współpracy, aby uzyskać zmiany przeglądane przez rówieśników.

  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 testowej lub UAT (testowania akceptacyjnego przez użytkowników), zespół przechodzi do wersji udostępnienia w Azure Pipelines i wdraża żądaną wersję fabryki deweloperskiej do UAT. To wdrożenie ma miejsce w ramach zadania Azure Pipelines i używa parametrów szablonu Resource Manager do zastosowania odpowiedniej konfiguracji.

  6. Po zweryfikowaniu zmian w fabryce testowej, wdróż je w fabryce produkcyjnej, korzystając z kolejnego zadania w ramach wydania potoków.

Uwaga

Tylko fabryka rozwoju 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 pipeline Azure DevOps lub szablonu zarządzania zasobami Azure.

Poniższy obraz podkreśla różne etapy tego cyklu życia.

Schemat ciągłej integracji z Azure Pipelines.

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

Jeśli korzystasz z integracji z Git w fabryce danych (Data Factory) i masz potok CI/CD, który przenosi zmiany ze środowiska deweloperskiego do testowego, a następnie do produkcyjnego, zalecamy następujące najlepsze praktyki:

  • Integracja z usługą Git. Skonfiguruj tylko swoją deweloperską fabrykę danych z integracją Git. Zmiany wdrażane do środowiska testowego i produkcyjnego są realizowane za pośrednictwem CI/CD (ciągła integracja/ciągłe wdrażanie) i nie wymagają integracji z Git.

  • Skrypt przed wdrożeniem i po wdrożeniu. Przed wykonaniem kroku wdrażania Resource Manager w ramach CI/CD, należy wykonać pewne zadania, takie jak zatrzymanie i restart wyzwalaczy oraz wyczyszczenie. 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ć lub włączyć tylko te wyzwalacze, które zostały zmodyfikowane, zamiast wyłączać lub włączać wszystkie wyzwalacze podczas procesów CI/CD (ciągłej integracji i 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 PowerShell i modułu Data Factory, możesz napotkać błędy deserializacji podczas uruchamiania poleceń.

  • Środowiska uruchomieniowe integracji i ich udostępnianie. Środowiska czasu wykonywania integracji nie zmieniają się często i są podobne na wszystkich etapach CI/CD. Data Factory oczekuje, że będziesz mieć tę samą nazwę, typ i podtyp runtime integracji na wszystkich etapach CI/CD. Jeśli chcesz udostępnić środowiska Integration Runtime na wszystkich etapach, rozważ użycie specjalnej fabryki tylko do przechowywania wspólnych ś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 samodzielnie hostowanego środowiska Integration Runtime. Azure SSIS Integration Runtime nie obsługują udostępniania.

  • Zarządzane wdrożenie 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.

  • Key Vault. Gdy korzystasz z usług połączonych, których informacje o połączeniu są przechowywane w Azure Key Vault, trzymaj oddzielne sejfy kluczy dla różnych środowisk. 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 tajemnic produkcyjnych. Jeśli zastosujesz tę metodę, zachowaj te same tajne nazwy na wszystkich etapach. Jeśli zachowasz te same nazwy wpisów tajnych, nie musisz parametryzować każdego łańcucha połączenia w środowiskach ciągłej integracji/ciągłego wdrażania, ponieważ jedyną rzeczą, która się zmienia, jest nazwa magazynu kluczy, co stanowi osobny parametr.

  • Nazewnictwo zasobów. Ze względu na ograniczenia szablonów ARM mogą pojawić się problemy przy wdrażaniu, jeśli zasoby zawierają spacje w nazwie. Zespół Azure Data Factory zaleca używanie znaków "_" lub "-" zamiast spacji dla zasobów. Na przykład 'Pipeline_1' jest lepszą nazwą niż 'Pipeline 1'.

  • Zmienianie repozytorium. Azure Data Factory (ADF) automatycznie zarządza treścią repozytorium Gita. Ręczna zmiana lub dodawanie niepowiązanych plików lub folderów do dowolnego miejsca w folderze danych ADF Git może powodować błędy ładowania zasobów. Na przykład obecność plików .bak może powodować błąd ADF CI/CD, więc usuń je, aby ADF mogło się załadować.

  • Kontrola ekspozycji i flagi funkcjonalności. Pracując w zespole, zdarza się, że można scalać zmiany, ale nie chcesz, aby działały w podwyższonych środowiskach, takich jak produkcja (PROD) czy kontrola jakości (QA). Aby obsłużyć ten scenariusz, zespół usługi ADF zaleca koncepcję DevOps polegającą na używaniu flag funkcji. W usłudze ADF można połączyć globalne parametry i aktywność warunku if, aby ukryć zestawy logiki na podstawie tych flag środowiska.

    Aby dowiedzieć się, jak ustawić flagę cech, zobacz poniższy wideoporadnik:

Nieobsługiwane funkcje

  • Data Factory z założenia nie obsługuje wybierania commitów ani selektywnego publikowania zasobów. Publikacja obejmuje wszystkie zmiany wprowadzone w fabryce danych.

    • Jednostki fabryki danych zależą od siebie. Na przykład wyzwalacze zależą od rurociągów danych, a rurociągi danych zależą od zestawów danych i innych rurociągów danych. 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 hotfixa. Aby uzyskać więcej informacji, zobacz temat Środowisko produkcyjne Hotfix.

  • Zespół Azure Data Factory nie zaleca przypisywania kontroli Azure RBAC do poszczególnych jednostek (na przykład potoków i zbiorów danych) 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 obrębie fabryki danych, rozważ wdrożenie 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żesz eksportować i importować alertów oraz metryk jako parametrów.

  • Częściowe szablony usługi Azure Resource Manager w gałęzi przeznaczonej do publikowania nie będą już obsługiwane od 1 listopada 2021 r. Jeśli Twój projekt korzystał z tej funkcji, przejdź na obsługiwany mechanizm wdrożeń poprzez użycie ARMTemplateForFactory.json plików or linkedTemplates .

    Diagram katalogu „PartialArmTemplates”.

Powiązana zawartość

  • Last updated on