Kontinuerlig integrering och leverans i Azure Data Factory

GÄLLER FÖR: Azure Data Factory Azure Synapse Analytics

Kontinuerlig integrering är en metod för att testa varje ändring som görs i din kodbas automatiskt och så tidigt som möjligt. Kontinuerlig leverans följer testerna som utförs vid den kontinuerliga integreringen och skickar ändringarna till ett mellanlagrings- eller produktionssystem.

I Azure Data Factory innebär kontinuerlig integrering och leverans (CI/CD) att datafabrikspipelines flyttas från en miljö (utveckling, test, produktion) till en annan. Azure Data Factory använder Azure Resource Manager-mallar för att lagra konfigurationen av dina olika Data Factory-enheter (till exempel pipelines, dataset och dataflöden). Det finns två föreslagna metoder för att flytta upp en datafabrik till en annan miljö:

• Automatiserad distribution genom att använda Data Factorys integration med Azure-pipelines
• Ladda upp en Resource Manager mall manuellt med hjälp av Data Factory UX-integrering med Azure Resource Manager.

CI/CD-livscykel

Följande översikt visar CI/CD-livscykeln i en Azure-datafabrik som är konfigurerad med Azure-lagringsplatser Git. Mer information om hur du konfigurerar en Git-lagringsplats finns i Source-kontroll i Azure Data Factory.

1. En utvecklingsdatafabrik skapas och konfigureras med Azure-lagringsplatser Git. Alla utvecklare bör ha behörighet att skapa Data Factory-resurser som pipelines och datauppsättningar.

2. En utvecklare skapar en funktionsgren för att göra en ändring. Signerade commits stöds inte i data factory. De felsöker sina pipelinekörningar med de senaste ändringarna. Mer information om hur du felsöker en pipelinekörning finns i Iterativ utveckling och felsökning med Azure Data Factory.

3. När en utvecklare är nöjd med sina ändringar skapar de en pull-förfrågan från sin funktionsgren till huvud- eller samarbetsgrenen för att få dem granskade av kollegor.

4. När en pull request har godkänts och ändringarna har sammanfogats i huvudgrenen, publiceras ändringarna till utvecklingsmiljön.

5. När teamet är redo att distribuera ändringarna till en test- eller UAT-fabrik (User Acceptance Testing) går teamet till sin Azure-pipelines version och distribuerar den önskade versionen av utvecklingsfabriken till UAT. Den här distributionen sker som en del av en Azure-pipelines uppgift och använder Resource Manager mallparametrar för att tillämpa lämplig konfiguration.

6. När ändringarna har verifierats i testfabriken distribuerar du till produktionsfabriken med hjälp av nästa uppgift i pipelineversionen.

Följande bild visar de olika stegen i denna livscykel.

Bästa praxis för CI/CD

Om du använder Git-integrering med din datafabrik och har en CI/CD-pipeline som flyttar dina ändringar från utveckling till test och sedan till produktion rekommenderar vi följande metodtips:

• Git-integrering. Konfigurera endast din utvecklingsdatafabrik med Git-integrering. Ändringar i test och produktion distribueras via CI/CD och behöver inte Git-integrering.

• Skript före och efter distribution. Innan Resource Manager-distributionssteget i CI/CD måste du slutföra vissa uppgifter, såsom att stoppa och starta om triggar och utföra städning. Vi rekommenderar att du använder PowerShell-skript före och efter distributionsuppgiften. Mer information finns i Uppdatera aktiva utlösare. Datafabriksteamet har angett ett skript som ska användas längst ned på den här sidan.

  Kommentar

  Använd PrePostDeploymentScript.Ver2.ps1 om du bara vill inaktivera/aktivera utlösare som har ändrats i stället för att aktivera alla utlösare under CI/CD.

  Varning

  Se till att använda PowerShell Core i ADO-uppgiften för att köra skriptet.

  Varning

  Om du inte använder de senaste versionerna av PowerShell och Data Factory-modulen kan du stöta på deserialiseringsfel när du kör kommandona.

• Integreringskörningar och delning. Integreringskörningar ändras inte ofta och är liknande över alla faser i din CI/CD. Så Data Factory förväntar sig att du har samma namn, typ och undertyp av integrationsruntime över alla steg av CI/CD. Om du vill dela integreringskörningar i alla faser bör du överväga att använda en ternary-fabrik bara för att innehålla de delade integrationskörningarna. Du kan använda den här delade fabriken i alla dina miljöer som en länkad integrationskörningstyp.

  Kommentar

  Integreringskörningsdelningen är endast tillgänglig för lokalt installerade integrationskörningar. Azure-SSIS-integreringskörningar stöder inte delning.

• Utplacering av hanterade privata slutpunkter. Om det redan finns en privat slutpunkt i en fabrik och du försöker distribuera en ARM-mall som innehåller en privat slutpunkt med samma namn, men med ändrade egenskaper, misslyckas distributionen. Med andra ord kan du distribuera en privat slutpunkt så länge den har samma egenskaper som den som redan finns i fabriken. Om någon egenskap skiljer sig åt mellan miljöerna kan du åsidosätta den genom att parametrisera den egenskapen och ange respektive värde under distributionen.

• Key Vault. När du använder länkade tjänster vars anslutningsinformation lagras i Azure Key Vault, håll separata nyckelvalv för olika miljöer. Du kan också konfigurera separata behörighetsnivåer för varje nyckelvalv. Du kanske till exempel inte vill att dina teammedlemmar ska ha behörighet till produktionshemligheter. Om du följer detta tillvägagångssätt, behåll samma hemliga namn över alla stadier. Om du behåller samma hemliga namn behöver du inte parameterisera varje reťazec pripojenia i CI/CD-miljöer eftersom det enda som ändras är nyckelvalvets namn, vilket är en separat parameter.

• Namngivning av resurser. På grund av begränsningar i ARM-mallen kan problem vid driftsättning uppstå om dina resurser innehåller mellanslag i namnet. Azure Data Factory-teamet rekommenderar att använda tecken som '_' eller '-' istället för blanksteg för resurser. Till exempel är 'Pipeline_1' ett föredraget namn framför 'Pipeline 1'.

• Ändrar lagringsplats. Azure Data Factory (ADF) hanterar automatiskt innehållet i Git-arkivet. Att manuellt ändra eller lägga till orelaterade filer eller mappar någonstans i ADF Git-arkivets datamapp kan orsaka fel vid resursladdning. Till exempel kan närvaron av .bak filer orsaka ADF CI/CD-fel, så ta bort dem för att ADF ska kunna laddas.

• Exponeringskontroll och funktionsflaggor. När man arbetar i team finns det tillfällen då man kan slå ihop ändringar, men inte vill att de ska köras i högre miljöer som produktion (PROD) och kvalitetskontroll (QA). För att hantera det här scenariot rekommenderar ADF-teamet DevOps-konceptet att använda funktionsflaggor. I ADF kan du kombinera globala parametrar och if-villkorsaktiviteten för att dölja uppsättningar av logik baserat på dessa miljöflaggor.

  För att lära dig hur man sätter upp en funktionsflagga, se följande videotutorial:

Funktioner som inte stöds

• Data Factory är avsiktligt utformat och stödjer inte selektiv utplockning av commits eller selektiv publicering av resurser. Publicering inkluderar alla ändringar som gjorts i datafabriken.

  • Datafabrikentiteter är beroende av varandra. Utlösare beror till exempel på pipelines och pipelines är beroende av datauppsättningar och andra pipelines. Selektiv publicering av en delmängd av resurser kan leda till oväntade beteenden och fel.
  • I sällsynta fall när du behöver selektiv publicering bör du överväga att använda en snabbkorrigering. Mer information finns i Produktionsmiljön för snabbkorrigeringar.

• Azure Data Factory-teamet rekommenderar inte att tilldela Azure RBAC-kontroller till enskilda enheter (till exempel pipelines och dataset) i en data factory. Om en utvecklare till exempel har åtkomst till en pipeline eller en datamängd ska utvecklaren kunna ha åtkomst till alla pipelines eller datamängder i datafabriken. Om du behöver implementera många Azure-roller i en datafabrik kan du överväga att distribuera ytterligare en datafabrik.

• Det går inte att publicera från privata grenar.

• Du kan för närvarande inte vara värd för projekt på Bitbucket.

• Du kan för närvarande inte exportera och importera varningar och mätvärden som parametrar.

• Partiella ARM-mallar i publiceringsgrenen stöds inte längre från och med den 1 november 2021. Om ditt projekt använde denna funktion, byt till en stödd mekanism för distributioner genom att använda ARMTemplateForFactory.json eller linkedTemplates filer.

  

Relaterat innehåll

• Förbättringar av kontinuerlig distribution
• Automatisera kontinuerlig integrering med Azure-pipelines versioner
• Manuellt främja en Resource Manager-produktionsmall till varje miljö
• Använd anpassade parametrar med en Resource Manager mall
• Länkade Resource Manager mallar
• Använda en produktionsmiljö för snabbkorrigering
• Exempelskript före och efter distribution