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) flytt av Data Factory-pipelines från en miljö (utveckling, testning, produktion) till en annan. Azure Data Factory använder Azure Resource Manager för att lagra konfigurationen av dina olika ADF-entiteter (pipelines, datauppsättningar, dataflöden och så vidare). Det finns två föreslagna metoder för att befordra en datafabrik till en annan miljö:

• Automatiserad distribution med Data Factory integrering med Azure Pipelines
• Ladda upp en Resource Manager manuellt med hjälp Data Factory UX-integrering med Azure Resource Manager.

CI/CD-livscykel

Nedan visas ett exempel på en översikt över CI/CD-livscykeln i en Azure-datafabrik som är konfigurerad med Azure Repos Git. Mer information om hur du konfigurerar en Git-lagringsplats finns i Källkontroll i Azure Data Factory.

1. En utvecklingsdatafabrik skapas och konfigureras med Azure Repos 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. De felsöker sina pipelinekörningar med sina senaste ändringar. Mer information om hur du felsöker en pipelinekörning finns i Iterativutveckling och felsökning med Azure Data Factory .

3. När en utvecklare är nöjd med sina ändringar skapar de en pull-begäran från funktionsgrenen till huvud- eller samarbetsgrenen för att få ändringarna granskade av peer-kollegor.

4. När en pull-begäran har godkänts och ändringar slås samman i main-grenen publiceras ändringarna till utvecklingsfabriken.

5. När teamet är redo att distribuera ändringarna till en test- eller UAT-fabrik (testning av användargodkännande) går teamet till sin Azure Pipelines-version och distribuerar önskad version av utvecklingsfabriken till UAT. Den här distributionen sker som en del av en Azure Pipelines-uppgift och använder Resource Manager 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 pipelines-versionen.

Bilden nedan visar de olika stegen i den här livscykeln.

Metodtips för CI/CD

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

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

• Skript före och efter distribution. Innan Resource Manager i CI/CD måste du utföra vissa uppgifter, till exempel stoppa och starta om utlösare och utföra rensning. 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.

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

• Distribution av hanterade privata slutpunkter. Om en privat slutpunkt redan finns 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 mellan miljöer kan du åsidosätta den genom att parameterisera 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 bör du behålla 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 teammedlemmarna ska ha behörighet till produktionshemligheter. Om du följer den här metoden rekommenderar vi att du behåller samma hemliga namn i alla steg. Om du behåller samma hemliga namn behöver du inte parametrisera varje anslutningssträng i CI/CD-miljöer eftersom det enda som ändras är nyckelvalvsnamnet, som är en separat parameter.

• Resursnamngivning. På grund av begränsningar i ARM-mallen kan problem i distributionen uppstå om dina resurser innehåller blanksteg i namnet. Den Azure Data Factory rekommenderar att du använder "_" eller "-" tecken i stället för blanksteg för resurser. Till exempel skulle "Pipeline_1" vara ett bättre namn än "Pipeline 1".

• Exponeringskontroll och funktionsflaggor. När du arbetar i ett team finns det instanser där du kan sammanfoga ändringar, men inte vill att de ska köras i förhöjda miljöer som PROD och 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.

  Information om hur du ställer in en funktionsflagga finns i videokursen nedan:

Funktioner som inte stöds

• Det är Data Factory inte tillåter att du väljer bort genomföranden eller selektiv publicering av resurser. Publiceringar innehåller alla ändringar som görs i datafabriken.

  • Datafabriksentiteter är beroende av varandra. Utlösare är till exempel beroende av 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.
  • Överväg att använda en snabbkorrigering i sällsynta fall när du behöver selektiv publicering. Mer information finns i Produktionsmiljö för snabbkorrigeringar.

• Teamet Azure Data Factory inte att tilldela Azure RBAC-kontroller till enskilda entiteter (pipelines, datauppsättningar osv.) i en datafabrik. 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 anser att du behöver implementera många Azure-roller i en datafabrik kan du titta på hur du distribuerar en andra datafabrik.

• Du kan inte publicera från privata grenar.

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

• För närvarande kan du inte exportera och importera aviseringar och matriser som parametrar.

• I koddatabasen under adf_publish-grenen läggs en mapp med namnet "PartialArmTemplates" för närvarande till bredvid mappen "linkedTemplates", "ARMTemplateForFactory.json" och "ARMTemplateParametersForFactory.json" som en del av publiceringen med källkontroll.

  

  Vi kommer inte längre att publicera "PartialArmTemplates" till adf_publish-grenen från och med 1-november 2021.

  Ingen åtgärd krävs om du inte använder PartialArmTemplates. Annars växlar du till en mekanism som stöds för distributioner med hjälp av: ARMTemplateForFactory.json- eller linkedTemplates-filer.

Nästa steg

• Automatisera kontinuerlig integrering med Azure Pipelines-versioner
• Höja upp en Resource Manager manuellt till varje miljö
• Använda anpassade parametrar med en Resource Manager mall
• Länkade Resource Manager mallar
• Använda en produktionsmiljö för snabbkorrigeringar
• Exempelskript före och efter distribution