Kontinuální integrace a doručování v Azure Data Factory

VZTAHUJE SE NA: Azure Data Factory Azure Synapse Analytics

Tip

Data Factory v Microsoft Fabric je nová generace Azure Data Factory s jednodušší architekturou, integrovanou AI a novými funkcemi. Pokud s integrací dat začínáte, začněte Fabric Data Factory. Stávající úlohy ADF lze upgradovat na Fabric pro přístup k novým funkcím v oblastech datové vědy, analýz v reálném čase a vytváření sestav.

• Začněte bezplatnou zkušební verzi Fabric.
• Upgrade z Azure Data Factory do služby Data Factory v Microsoft Fabric

Kontinuální integrace je postup testování každé změny provedené v základu kódu automaticky a co nejdříve. Kontinuální doručování následuje po testování v rámci kontinuální integrace a nasadí změny do přípravného nebo produkčního systému.

V Azure Data Factory znamená kontinuální integrace a doručování (CI/CD) přesun kanálů služby Data Factory z jednoho prostředí (vývoj, testování, produkce) do jiného. Azure Data Factory využívá šablony Azure Resource Manager k ukládání konfigurace různých entit ADF (kanály, datové sady, toky dat atd.). Existují dvě navrhované metody, jak přenést datovou továrnu do jiného prostředí:

• Automatizované nasazení s využitím integrace služby Data Factory s Azure Pipelines
• Ručně nahrajte šablonu Resource Manager pomocí integrace uživatelského rozhraní služby Data Factory s Azure Resource Manager.

Poznámka:

K interakci s Azure doporučujeme použít modul Azure Az PowerShell. Pokud chcete začít, přečtěte si téma Install Azure PowerShell. Informace o migraci do modulu Az PowerShell najdete v tématu Migrace Azure PowerShell z AzureRM do Az.

Životní cyklus CI/CD

Poznámka:

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

Níže najdete ukázkový přehled životního cyklu CI/CD v datové továrně Azure, která je nakonfigurovaná s Azure Repos Gitem. Další informace o konfiguraci úložiště Git najdete v tématu Zdrojový ovládací prvek v Azure Data Factory.

1. Vytvoří se a nakonfiguruje vývojová datová továrna s Azure Repos Gitem. 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. Podepsané commity nejsou v Data Factory podporovány. Ladí spouštění potrubí se svými nejnovějšími změnami. Další informace o ladění spuštění pipeline najdete v části Iterativní vývoj a ladění pomocí Azure Data Factory.

3. Až bude vývojář spokojen se svými změnami, vytvoří pull request ze své funkční větve do hlavní větve nebo větve pro spolupráci, aby kolegové zkontrolovali změny.

4. Po schválení pull requestu a sloučení změn v hlavní větvi se změny publikují do vývojového prostředí.

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 své Azure Pipelines verze 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 Manager k použití příslušné konfigurace.

6. Po ověření změn v testovací továrně nasadit do produkční továrny pomocí dalšího úkolu vypuštění pipeline.

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.

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 Manager v CI/CD musíte dokončit určité úlohy, jako je zastavení a restartování triggerů a vyč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:

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

  Varování

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

  Varování

  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í pro integraci a sdílení Prostředí pro integraci (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. Azure-SSIS Integration Runtime nepodporuje 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é v 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íčů. Například možná nechcete, aby členové vašeho týmu měli oprávnění k produkčním tajným datů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é connection string 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 místo mezer pro prostředky doporučuje 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. Ruční úprava nebo přidání nesouvisejících souborů nebo složek do kterékoliv datové složky v rámci úložiště ADF Git může způsobit chyby při načítání prostředků. Například přítomnost souborů .bak může způsobit chybu v rámci CI/CD procesu ADF, takže by měly být odstraněny, aby se ADF mohla načíst.

• Řízení přístupových oprávnění a funkční vlajky. 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 použití příznaků funkcí. V ADF můžete kombinovat globální parametry a aktivitu podmínky 'if' k maskování logických sad na základě těchto příznaků prostředí.

  Chcete-li se naučit, jak nastavit feature flag, podívejte se na níže uvedený video tutoriál:

Nepodporované funkce

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

  • Entity datové továrny jsou závislé na sobě navzájem. Spouště například závisejí na kanálech a kanály závisí na datových sadách a jiných kanálech. Selektivní zveřejnění podmnožiny 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í hotfix. Další informace naleznete v tématu Hotfix produkčním prostředí.

• Tým Azure Data Factory nedoporučuje přiřazovat řízení Azure RBAC jednotlivým entitám (kanálům, datovým sadám atd.) v rámci datové továrny. 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 datové továrně, podívejte se na nasazení druhé datové továrny.

• Nemůžete publikovat z soukromý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.

• Částečné šablony ARM ve vaší větvi pro publikování se už od 1. listopadu 2021 nepodporují. Pokud váš projekt tuto funkci využil, přepněte na podporovaný mechanismus nasazení pomocí těchto ARMTemplateForFactory.json souborů nebo linkedTemplates souborů.

  

Související obsah

• Vylepšení průběžného nasazování
• Automatizujte kontinuální integraci pomocí vydání Azure Pipelines
• Manuálně nasadit šablonu Správce prostředků do každého prostředí
• Použití vlastních parametrů pomocí šablony Resource Manager
• Propojené šablony Resource Manageru
• Použití produkčního prostředí pro hotfixy
• Ukázkový skript před nasazením a po nasazení