Kontinuální integrace a průběžné doručování ve službě Azure Data Factory

  • Článek

PLATÍ PRO: Azure Data Factory Azure Synapse Analytics

Tip

Vyzkoušejte si službu Data Factory v Microsoft Fabric, řešení pro analýzy typu all-in-one pro podniky. Microsoft Fabric zahrnuje všechno od přesunu dat až po datové vědy, analýzy v reálném čase, business intelligence a vytváření sestav. Přečtěte si, jak začít používat novou zkušební verzi zdarma.

Kontinuální integrace je postup testování každé změny provedené v základu kódu automaticky a co nejdříve. Po testování v rámci kontinuální integrace dochází k průběžnému doručování, kdy se změny nasdílí do přípravného nebo produkčního systému.

Ve službě Azure Data Factory kontinuální integrace a průběžné doručování (CI/CD) představují přesun kanálů Data Factory z jednoho prostředí (vývojového, testovacího, produkčního) do jiného. Azure Data Factory využívá šablony Azure Resource Manageru k ukládání konfigurace různých entit ADF (kanálů, datových sad, toků dat atd.). Existují dvě navrhované metody pro zvýšení úrovně datové továrny do jiného prostředí:

  • Automatizované nasazení s využitím integrace služby Data Factory se službou Azure Pipelines
  • Ruční nahrání šablony Resource Manageru pomocí integrace uživatelského prostředí služby Data Factory s Azure Resource Managerem

Poznámka:

Při práci s Azure doporučujeme používat modul Azure Az PowerShellu. Začněte tím, že si projdete téma Instalace Azure PowerShellu. Informace o tom, jak migrovat na modul Az PowerShell, najdete v tématu Migrace Azure PowerShellu z AzureRM na Az.

Životní cyklus CI/CD

Poznámka:

Další informace najdete v tématu Vylepšení průběžného nasazování.

Níže je ukázkový přehled životního cyklu CI/CD v datové továrně Azure, který je nakonfigurovaný s Gitem Azure Repos. Další informace o konfiguraci úložiště Git najdete v tématu Správa zdrojového kódu ve službě Azure Data Factory.

  1. Vytvoří se a nakonfiguruje vývojová datová továrna s Gitem Azure Repos. Všichni vývojáři by měli mít oprávnění k vytváření prostředků služby Data Factory, jako jsou kanály a datové sady.

  2. Vývojář vytvoří větev funkce, která provede změnu. Ladí spuštění kanálu s nejnovějšími změnami. Další informace o ladění spuštění kanálu najdete v tématu Iterativní vývoj a ladění pomocí služby Azure Data Factory.

  3. Jakmile vývojář bude s jejich změnami spokojen, vytvoří žádost o přijetí změn ze své větve funkcí do hlavní větve nebo větve pro spolupráci, aby si změny zkontrolovali kolegové.

  4. Po schválení žádosti o přijetí změn a sloučení změn v hlavní větvi se změny publikují do vývojové továrny.

  5. Jakmile je tým připravený k nasazení změn do továrny pro testování nebo testování přijetí uživatelem (User Acceptance Testing), tým přejde do verze Azure Pipelines a nasadí požadovanou verzi vývojové továrny do UAT. Toto nasazení probíhá jako součást úlohy Azure Pipelines a používá parametry šablony Resource Manageru k použití příslušné konfigurace.

  6. Po ověření změn v testovací továrně nasaďte do produkční továrny pomocí další úlohy verze kanálů.

Poznámka:

K úložišti Git je přidružená pouze vývojová továrna. Testovací a produkční továrny by k nim neměly mít přidružené úložiště Git a měly by se aktualizovat pouze prostřednictvím kanálu Azure DevOps nebo šablony správy prostředků.

Na následujícím obrázku jsou zvýrazněné různé kroky tohoto životního cyklu.

Diagram of continuous integration with Azure Pipelines

Osvědčené postupy pro CI/CD

Pokud používáte integraci Gitu s datovou továrnou a máte kanál CI/CD, který přesouvá vaše změny z vývoje do testování a pak do produkčního prostředí, doporučujeme tyto osvědčené postupy:

  • Integrace Gitu Nakonfigurujte pouze vývojovou datovou továrnu s integrací Gitu. Změny v testování a produkčním prostředí se nasazují přes CI/CD a nepotřebují integraci Gitu.

  • Skript před nasazením a po nasazení Před krokem nasazení Resource Manageru v CI/CD musíte dokončit určité úlohy, jako je zastavení a restartování triggerů a provádění čištění. Doporučujeme použít skripty PowerShellu před a po úloze nasazení. Další informace najdete v tématu Aktualizace aktivních aktivačních událostí. Tým datové továrny poskytl skript pro použití umístěný v dolní části této stránky.

    Poznámka:

    PrePostDeploymentScript.Ver2.ps1 použijte, pokud chcete vypnout nebo zapnout pouze triggery, které byly upraveny, místo aby se všechny triggery vypnuly nebo zapnuly během CI/CD.

    Upozorňující

    Ujistěte se, že ke spuštění skriptu používáte PowerShell Core v úloze ADO.

    Upozorňující

    Pokud nepoužíváte nejnovější verze modulu PowerShell a Data Factory, při spouštění příkazů můžete narazit na chyby deserializace.

  • Prostředí Integration Runtime a sdílení Prostředí Integration Runtime se často nemění a jsou podobné ve všech fázích ci/CD. Data Factory proto očekává, že budete mít stejný název, typ a podtyp prostředí Integration Runtime ve všech fázích CI/CD. Pokud chcete sdílet prostředí Integration Runtime napříč všemi fázemi, zvažte použití ternární továrny, která bude obsahovat sdílené prostředí Integration Runtime. Tuto sdílenou továrnu můžete použít ve všech vašich prostředích jako propojený typ prostředí Integration Runtime.

    Poznámka:

    Sdílení prostředí Integration Runtime je k dispozici pouze pro místní prostředí Integration Runtime. Prostředí Azure-SSIS Integration Runtime nepodporují sdílení.

  • Nasazení spravovaného privátního koncového bodu Pokud už privátní koncový bod v továrně existuje a pokusíte se nasadit šablonu ARM, která obsahuje privátní koncový bod se stejným názvem, ale s upravenými vlastnostmi, nasazení se nezdaří. Jinými slovy, můžete úspěšně nasadit privátní koncový bod, pokud má stejné vlastnosti jako ten, který už v továrně existuje. Pokud se některá vlastnost v jednotlivých prostředích liší, můžete ji přepsat parametrizací této vlastnosti a zadáním příslušné hodnoty během nasazení.

  • Key Vault. Pokud používáte propojené služby, jejichž informace o připojení jsou uložené ve službě Azure Key Vault, doporučujeme uchovávat samostatné trezory klíčů pro různá prostředí. Můžete také nakonfigurovat samostatné úrovně oprávnění pro každý trezor klíčů. Můžete například chtít, aby členové vašeho týmu měli oprávnění k produkčním tajným kódům. Pokud postupujete podle tohoto přístupu, doporučujeme zachovat stejné názvy tajných kódů ve všech fázích. Pokud zachováte stejné názvy tajných kódů, nemusíte parametrizovat jednotlivé připojovací řetězec napříč prostředími CI/CD, protože jedinou věcí, kterou změníte, je název trezoru klíčů, což je samostatný parametr.

  • Pojmenování prostředků Kvůli omezením šablony ARM můžou nastat problémy s nasazením, pokud vaše prostředky obsahují mezery v názvu. Tým Azure Data Factory doporučuje místo mezer pro prostředky používat znaky _nebo -. Například "Pipeline_1" by byl vhodnější název než "Kanál 1".

  • Změna úložiště. ADF spravuje obsah úložiště GIT automaticky. Změna nebo přidání ručně nesouvisejících souborů nebo složek do libovolné složky dat úložiště ADF v úložišti Git může způsobit chyby načítání prostředků. Například přítomnost souborů .bak může způsobit chybu CI/CD ADF, takže by se měly odebrat, aby se ADF načetla.

  • Řízení expozice a příznaky funkcí. Při práci v týmu existují instance, ve kterých můžete sloučit změny, ale nechcete je spouštět v prostředí se zvýšenými oprávněními, jako je NAPŘÍKLAD PROD a QA. Pro zpracování tohoto scénáře doporučuje tým ADF koncept DevOps při používání příznaků funkcí. V ADF můžete kombinovat globální parametry a aktivitu podmínky if ke skrytí sad logiky na základě těchto příznaků prostředí.

    Informace o nastavení příznaku funkce najdete v následujícím videokurzu:

Nepodporované funkce

  • Služba Data Factory záměrně neumožňuje výběr potvrzení ani selektivní publikování prostředků. Publikování bude zahrnovat všechny změny provedené v datové továrně.

    • Entity datové továrny jsou závislé na sobě navzájem. Triggery například závisejí na kanálech a kanály závisí na datových sadách a dalších kanálech. Selektivní publikování podmnožina prostředků může vést k neočekávanému chování a chybám.
    • Ve výjimečných případech, kdy potřebujete selektivní publikování, zvažte použití opravy hotfix. Další informace naleznete v tématu Oprava hotfix produkční prostředí.

  • Tým Azure Data Factory nedoporučuje přiřazovat ovládací prvky Azure RBAC jednotlivým entitám (kanálům, datovým sadám atd.) v datové továrně. Pokud má například vývojář přístup ke kanálu nebo k datové sadě, měl by mít přístup ke všem kanálům nebo datovým sadám v datové továrně. Pokud máte pocit, že potřebujete implementovat mnoho rolí Azure v rámci datové továrny, podívejte se na nasazení druhé datové továrny.

  • Nemůžete publikovat z privátních větví.

  • V současné době nemůžete hostovat projekty v Bitbucketu.

  • V současné době není možné exportovat a importovat upozornění a matice jako parametry.

  • V úložišti kódu ve větvi adf_publish se v současné době přidá složka s názvem PartialArmTemplates vedle složky linkedTemplates, ARMTemplateForFactory.json a ARMTemplateParametersForFactory.json jako součást publikování pomocí správy zdrojového kódu.

    Diagram of 'PartialArmTemplates' folder.

    Od 1. listopadu 2021 už nebudeme publikovat "PartialArmTemplates" do větve adf_publish .

    Pokud nepoužíváte partialArmTemplates, nevyžaduje se žádná akce. V opačném případě přepněte na jakýkoli podporovaný mechanismus pro nasazení pomocí souborů ARMTemplateForFactory.json nebo linkedTemplates.

Související obsah