Continuous integration and delivery in Azure Data Factory

A következőkre vonatkozik: Azure Data Factory Azure Synapse Analytics

Tipp.

Próbálja ki a Data Factoryt a Microsoft Fabricben, amely egy teljes körű elemzési megoldás a nagyvállalatok számára. A Microsoft Fabric az adattovábbítástól az adatelemzésig, a valós idejű elemzésig, az üzleti intelligenciáig és a jelentéskészítésig mindent lefed. Ismerje meg, hogyan indíthat új próbaverziót ingyenesen!

A folyamatos integráció az a gyakorlat, hogy a kódbázison végrehajtott minden módosítást automatikusan és a lehető leghamarabb tesztel. Continuous delivery follows the testing that happens during continuous integration and pushes changes to a staging or production system.

In Azure Data Factory, continuous integration and delivery (CI/CD) means moving Data Factory pipelines from one environment (development, test, production) to another. Az Azure Data Factory Azure Resource Manager-sablonokkal tárolja a különböző ADF-entitások (folyamatok, adathalmazok, adatfolyamok stb.) konfigurációját. Az adat-előállítók egy másik környezetbe való előléptetéséhez két javasolt módszer létezik:

  • Automatizált üzembe helyezés a Data Factory És az Azure Pipelines integrációjával
  • Manuálisan töltsön fel egy Resource Manager-sablont a Data Factory UX-integrációjával az Azure Resource Managerrel.

Megjegyzés:

We recommend that you use the Azure Az PowerShell module to interact with Azure. See Install Azure PowerShell to get started. To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.

CI/CD életciklusa

Megjegyzés:

További információ: Folyamatos üzembe helyezési fejlesztések.

Az alábbiakban az Azure Repos Gittel konfigurált Azure Data Factory CI/CD-életciklusának áttekintését tekintjük át. A Git-adattár konfigurálásáról további információt az Azure Data Factory forrásvezérlőjében talál.

  1. Létrejön és konfigurál egy fejlesztői adat-előállítót az Azure Repos Gittel. Minden fejlesztőnek rendelkeznie kell engedéllyel Data Factory-erőforrások, például folyamatok és adathalmazok létrehozásához.

  2. A fejlesztő létrehoz egy funkcióágat a módosításhoz. A legutóbbi módosításokkal hibakeresést hajtanak végre a folyamatfuttatásaikban. A folyamatfuttatások hibakeresésével kapcsolatos további információkért tekintse meg az Iteratív fejlesztés és hibakeresés az Azure Data Factoryvel című témakört.

  3. Miután a fejlesztő elégedett a módosításokkal, létrehoz egy lekéréses kérelmet a szolgáltatáságból a fő vagy együttműködési ágba, hogy a módosításokat a társviszonyok felülvizsgálják.

  4. A lekéréses kérelem jóváhagyása és a módosítások a főágban való egyesítése után a módosítások közzé lesznek téve a fejlesztői gyárban.

  5. Ha a csapat készen áll a módosítások tesztelési vagy felhasználói elfogadási tesztüzemben való üzembe helyezésére, a csapat az Azure Pipelines kiadására lép, és üzembe helyezi a fejlesztői gyár kívánt verzióját a UAT-ben. Ez az üzembe helyezés egy Azure Pipelines-feladat részeként történik, és Resource Manager-sablonparaméterekkel alkalmazza a megfelelő konfigurációt.

  6. Miután ellenőrizte a módosításokat a teszt-előállítóban, helyezze üzembe az éles üzemben a folyamatok kiadásának következő feladatával.

Megjegyzés:

Csak a fejlesztői gyár van hozzárendelve egy git-adattárhoz. A teszt- és éles üzemeket nem szabad git-adattárral társítani, és csak Azure DevOps-folyamaton vagy erőforrás-kezelési sablonon keresztül kell frissíteni.

Az alábbi kép az életciklus különböző lépéseit emeli ki.

Diagram of continuous integration with Azure Pipelines

Ajánlott eljárások a CI/CD-hez

Ha Git-integrációt használ az adat-előállítóval, és rendelkezik egy CI/CD-folyamattal, amely a fejlesztésről a tesztelésre, majd az éles környezetbe helyezi át a módosításokat, az alábbi ajánlott eljárásokat javasoljuk:

  • Git-integráció. Csak a fejlesztői adat-előállítót konfigurálja Git-integrációval. A teszteléshez és az éles környezethez szükséges módosítások CI/CD-n keresztül lesznek üzembe helyezve, és nincs szükség Git-integrációra.

  • Üzembe helyezés előtti és utáni szkript. A Ci/CD Resource Manager üzembe helyezési lépése előtt el kell végeznie bizonyos feladatokat, például az eseményindítók leállítását és újraindítását, valamint a törlést. Javasoljuk, hogy az üzembe helyezési feladat előtt és után használjon PowerShell-szkripteket. További információ: Aktív eseményindítók frissítése. A data factory csapata adott meg egy szkriptet , amelyet a lap alján használhat.

    Megjegyzés:

    Használja a PrePostDeploymentScript.Ver2.ps1 parancsot, ha csak azokat az eseményindítókat szeretné kikapcsolni/ bekapcsolni, amelyeket módosítottak a CI/CD alatt.

    Figyelmeztetés

    A szkript futtatásához mindenképpen használja a PowerShell Core-t az ADO-feladatban.

    Figyelmeztetés

    Ha nem a PowerShell és a Data Factory modul legújabb verzióit használja, deszerializálási hibákba ütközhet a parancsok futtatása közben.

  • Integrációs futtatókörnyezetek és megosztás. Az integrációs futtatókörnyezetek nem változnak gyakran, és a CI/CD minden szakaszában hasonlóak. A Data Factory tehát azt várja, hogy a CI/CD minden szakaszában ugyanazzal a névvel, típussal és altípussal rendelkezzen az integrációs futtatókörnyezethez. Ha minden fázisban meg szeretné osztani az integrációs futtatókörnyezeteket, fontolja meg, hogy csak a megosztott integrációs futtatókörnyezeteket tartalmazza egy ternáris gyár használatával. Ezt a megosztott gyárat az összes környezetben használhatja csatolt integrációs modultípusként.

    Megjegyzés:

    Az integrációs modul megosztása csak saját üzemeltetésű integrációs futtatókörnyezetekhez érhető el. Az Azure-SSIS integrációs futtatókörnyezetek nem támogatják a megosztást.

  • Felügyelt privát végpont üzembe helyezése. Ha egy privát végpont már létezik egy gyárban, és olyan ARM-sablont próbál üzembe helyezni, amely azonos nevű, de módosított tulajdonságokkal rendelkező privát végpontot tartalmaz, az üzembe helyezés sikertelen lesz. In other words, you can successfully deploy a private endpoint as long as it has the same properties as the one that already exists in the factory. If any property is different between environments, you can override it by parameterizing that property and providing the respective value during deployment.

  • Key Vault. Ha olyan társított szolgáltatásokat használ, amelyek kapcsolati adatait az Azure Key Vault tárolja, ajánlott külön kulcstartókat tartani a különböző környezetekhez. Az egyes kulcstartókhoz külön engedélyszinteket is konfigurálhat. Előfordulhat például, hogy nem szeretné, hogy a csapattagok rendelkezzenek engedélyekkel az éles titkos kulcsokhoz. Ha ezt a megközelítést követi, javasoljuk, hogy minden fázisban tartsa meg ugyanazokat a titkos neveket. Ha megtartja ugyanazokat a titkos kódneveket, nem kell minden kapcsolati sztring paramétereznie a CI/CD-környezetekben, mert csak a kulcstartó neve változik, amely egy külön paraméter.

  • Erőforrás elnevezése. Az ARM-sablon korlátai miatt az üzembe helyezés során problémák léphetnek fel, ha az erőforrások szóközöket tartalmaznak a névben. Az Azure Data Factory csapata "_" vagy "-" karakterek használatát javasolja az erőforrások szóközei helyett. A "Pipeline_1" például előnyösebb név lenne az 1. folyamatnál.

  • Az adattár módosítása. Az ADF automatikusan kezeli a GIT-adattár tartalmát. Ha manuálisan nem kapcsolódó fájlokat vagy mappákat módosít vagy vesz fel az ADF Git-adattár adatmappájában, az erőforrás-betöltési hibákat okozhat. A .bak-fájlok jelenléte például ADF CI/CD-hibát okozhat, ezért el kell távolítani őket, hogy az ADF betöltse őket.

  • Expozíció-vezérlés és funkciójelzők. Ha csapatban dolgozik, vannak olyan példányok, ahol egyesítheti a módosításokat, de nem szeretné, hogy emelt szintű környezetekben, például PROD-ben és minőségbiztosítási környezetben fussanak. A forgatókönyv kezeléséhez az ADF csapata javasolja a DevOps szolgáltatásjelzők használatának fogalmát. Az ADF-ben kombinálhatja a globális paramétereket és az if condition tevékenységet , hogy elrejtse a logikai csoportokat ezen környezeti jelzők alapján.

    A funkciójelző beállításáról az alábbi oktatóvideóból tájékozódhat:

Nem támogatott funkciók

  • A Data Factory nem teszi lehetővé a véglegesítések kiválasztását vagy az erőforrások szelektív közzétételét. A közzétételek tartalmazzák az adat-előállítóban végrehajtott összes módosítást.

    • Az adat-előállító entitásai egymástól függenek. Az eseményindítók például a folyamatoktól, a folyamatok pedig az adathalmazoktól és más folyamatoktól függnek. Az erőforrások egy részhalmazának szelektív közzététele váratlan viselkedéshez és hibákhoz vezethet.
    • Ritkán, amikor szelektív közzétételre van szüksége, fontolja meg egy gyorsjavítás használatát. További információt a gyorsjavítás éles környezetében talál.
  • Az Azure Data Factory csapata nem javasolja az Azure RBAC-vezérlők hozzárendelését az egyes entitásokhoz (folyamatokhoz, adathalmazokhoz stb.) egy adat-előállítóban. For example, if a developer has access to a pipeline or a dataset, they should be able to access all pipelines or datasets in the data factory. Ha úgy érzi, hogy számos Azure-szerepkört kell implementálnia egy adat-előállítóban, tekintse meg egy második adat-előállító üzembe helyezését.

  • Privát ágakból nem végezhető közzététel.

  • A Bitbucketen jelenleg nem lehet projekteket üzemeltetni.

  • Jelenleg nem exportálhat és importálhat riasztásokat és mátrixokat paraméterekként.

  • A adf_publish ág alatti kódtárban jelenleg egy "PartialArmTemplates" nevű mappa jelenik meg a "linkedTemplates" mappa, az "ARMTemplateForFactory.json" és az "ARMTemplateParametersForFactory.json" fájl mellett a forrásvezérlővel történő közzététel részeként.

    Diagram of 'PartialArmTemplates' folder.

    2021. november 1-től kezdve nem tesszük közzé a "PartialArmTemplates" elemet a adf_publish ágban.

    Csak akkor van szükség műveletre, ha a "PartialArmTemplates" parancsot használja. Ellenkező esetben váltson az üzemelő példányok bármely támogatott mechanizmusára az "ARMTemplateForFactory.json" vagy a "linkedTemplates" fájlok használatával.