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

PLATÍ PRO: Azure Data Factory Azure Synapse Analytics

Kontinuální integrace je postup, jak každou změnu provedenou v kódu automaticky a co nejdříve testovat. 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á Azure Resource Manager 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í podpory datové továrny do jiného prostředí:

• Automatizované nasazení s Data Factory integrací s Azure Pipelines
• Ručně nahrajte šablonu Resource Manager pomocí Data Factory uživatelského rozhraní s Azure Resource Manager.

Životní cyklus CI/CD

Níže je uvedený ukázkový přehled životního cyklu CI/CD v datové továrně Azure, která je nakonfigurovaná Azure Repos Gitu. Další informace o tom, jak nakonfigurovat úložiště Git, najdete v tématu Source control in Azure Data Factory.

1. Vytvoří se vývojová datová továrna, která se konfiguruje Azure Repos Gitu. Všichni vývojáři by měli mít oprávnění vytvářet Data Factory, jako jsou kanály a datové sady.

2. Vývojář vytvoří větev funkce, ve které může provést změnu. S nejnovějšími změnami ladí spuštění kanálu. Další informace o ladění spuštění kanálu najdete v tématu Iterativní vývoja ladění pomocí Azure Data Factory .

3. Jakmile je vývojář se svými změnami spokojen, vytvoří žádost o získání změn ze své větve funkcí do hlavní větve nebo větve spolupráce, aby změny přehodnotili kolegové.

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

5. Když je tým připravený nasadit změny do testovací továrny nebo do továrny UAT (User Acceptance Testing), přejde do své 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á Resource Manager šablony k použití příslušné konfigurace.

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

Následující obrázek ukazuje různé kroky tohoto životního cyklu.

Osvědčené postupy pro CI/CD

Pokud používáte integraci Gitu se svou datovou továrnou a máte kanál CI/CD, který přesouvá změny z vývoje do testovacího a potom 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 produkci se nasadí prostřednictvím CI/CD a nepomáhou integraci Gitu.

• Skript před a po nasazení. Před zahájením Resource Manager CI/CD musíte dokončit určité úlohy, jako je zastavení a restartování triggerů a vyčištění. Před a po dokončení úlohy nasazení doporučujeme používat skripty PowerShellu. Další informace najdete v tématu Aktualizace aktivních triggerů. Tým datové továrny poskytl skript, který se má použít v dolní části této stránky.

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

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

• 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í. Pro každý trezor klíčů můžete také nakonfigurovat samostatné úrovně oprávnění. Například možná nechcete, aby členové vašeho týmu měli oprávnění k produkčním tajným kódům. Pokud tento přístup dodržujete, doporučujeme zachovat stejné názvy tajných názvů ve všech fázích. Pokud si zachováte stejné názvy tajných klíčů, nemusíte parametrizovat každý připojovací řetězec v různých prostředích CI/CD, protože jediný, co se změní, je název trezoru klíčů, což je samostatný parametr.

• Pojmenování prostředků. Z důvodu omezení šablon ARM může dojít k problémům s nasazením, pokud vaše prostředky obsahují v názvu mezery. Tým Azure Data Factory pro prostředky místo mezer použít znaky _nebo -. Například "Pipeline_1" by byl vhodnější název než "Kanál 1".

• Řízení vystavení a příznaky funkcí. Při práci v týmu existují případy, kdy můžete sloučit změny, ale nechcete je spouštět v prostředích se zvýšenými oprávněními, jako je prod nebo qa. V rámci tohoto scénáře tým ADF doporučuje DevOps používání příznaků funkcí. V ADF můžete kombinovat globální parametry a aktivitu podmínky if, abyste na základě těchto příznaků prostředí skryli sady logiky.

  Informace o nastavení příznaku funkce najdete v následujícím výukovém videu:

Nepodporované funkce

• Z Data Factory neumožňují vybírání potvrzení nebo selektivní publikování prostředků. Publikování bude obsahovat všechny změny provedené v datové továrně.

  • Entity datové továrny na sobě navzájem závisejí. Triggery například závisí na kanálech a kanály závisí na datových sadách a dalších kanálech. Selektivní publiková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í opravy hotfix. Další informace najdete v tématu Produkční prostředí oprav hotfix.

• 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 v rámci datové továrny potřebujete implementovat mnoho rolí Azure, podívejte se na nasazení druhé datové továrny.

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

• V současnosti nemůžete hostovat projekty v Bitbucketu.

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

• V úložišti kódu ve větvi adf_publish se v rámci publikování pomocí správy zdrojového kódu přidá složka PartialArmTemplates vedle souborů linkedTemplates, ARMTemplateForFactory.json a ARMTemplateParametersForFactory.json.

  

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

  Pokud používáte PartialArmTemplates, nevyžaduje se žádná akce. Jinak přepněte na jakýkoli podporovaný mechanismus pro nasazení pomocí souborů ARMTemplateForFactory.json nebo linkedTemplates.

Další kroky

• Automatizace kontinuální integrace s využitím Azure Pipelines verzí
• Ruční zvýšení Resource Manager šablony pro každé prostředí
• Použití vlastních parametrů s Resource Manager šablonou
• Propojené Resource Manager šablony
• Použití produkčního prostředí oprav hotfix
• Ukázkový skript před a po nasazení