Föregående

Nästa

Löpande integrering och distribution

Slutförd

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-mallar för att lagra konfigurationen av dina olika Azure Data Factory-entiteter (pipelines, datauppsättningar, dataflöden och så vidare). Det finns två föreslagna metoder för att flytta upp en datafabrik till en annan miljö:

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

Livscykel för kontinuerlig integrering/kontinuerlig leverans

Nedan visas en exempelöversikt över CI/CD-livscykeln i en Azure-datafabrik som har konfigurerats med Azure Repos Git.

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 de senaste ändringarna.

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å sina ändringar granskade av peer-datorer.

4. När en pull-begäran har godkänts och ändringarna har sammanfogats i huvudgrenen publiceras ändringarna till utvecklingsfabriken.

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.

Kommentar

Endast utvecklingsfabriken är associerad med en git-lagringsplats. Test- och produktionsfabrikerna bör inte ha en git-lagringsplats som är associerad med dem och bör endast uppdateras via en Azure DevOps-pipeline eller via en resource management-mall.

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

Automatisera kontinuerlig integrering med hjälp av Azure Pipelines-versioner

Följande är en guide för att konfigurera en Azure Pipelines-version som automatiserar distributionen av en datafabrik till flera miljöer.

Behov

• En Azure-prenumeration som är länkad till Visual Studio Team Foundation Server eller Azure Repos som använder Azure Resource Manager-tjänstslutpunkten

• En datafabrik som konfigurerats med Azure Repos Git-integrering.

• Ett Azure-nyckelvalv som innehåller hemligheterna för varje miljö.

Konfigurera en Azure Pipelines-version

1. I Azure DevOps öppnar du projektet som har konfigurerats med din datafabrik.

2. Till vänster på sidan väljer du Pipelines och sedan Versioner.

   

3. Välj Ny pipeline, eller om du har befintliga pipelines väljer du Ny och sedan Ny versionspipeline.

4. Välj mallen Tomt jobb .

   

5. I rutan Fasnamn anger du namnet på din miljö.

6. Välj Lägg till artefakt och välj sedan git-lagringsplatsen som konfigurerats med din utvecklingsdatafabrik. Välj publiceringsgrenen för lagringsplatsen för standardgrenen. Som standard är adf_publishden här publiceringsgrenen . Som Standardversion väljer du Senaste från standardgrenen.

   

7. Lägg till en Azure Resource Manager-distributionsuppgift:

   a. I fasvyn väljer du Visa stegaktiviteter.

   

   b. Skapa en ny uppgift. Sök efter ARM-malldistribution och välj sedan Lägg till.

   c. I distributionsaktiviteten väljer du prenumerationen, resursgruppen och platsen för måldatafabriken. Ange autentiseringsuppgifter om det behövs.

   d. I listan Åtgärd väljer du Skapa eller uppdatera resursgrupp.

   e. Välj ellipsknappen (...) bredvid rutan Mall . Bläddra efter Azure Resource Manager-mallen som genereras i publiceringsgrenen för den konfigurerade git-lagringsplatsen. Leta efter filen ARMTemplateForFactory.json i <FactoryName> mappen för adf_publish-grenen.

   f. Välj ... bredvid rutan Mallparametrar för att välja parameterfilen. Leta efter filen ARMTemplateParametersForFactory.json i <FactoryName> mappen för adf_publish-grenen.

   g. Välj ... bredvid rutan Åsidosätt mallparametrar och ange önskade parametervärden för måldatafabriken. För autentiseringsuppgifter som kommer från Azure Key Vault anger du hemlighetens namn mellan dubbla citattecken. Om till exempel hemlighetens namn är cred1 anger du "$(cred1)" för det här värdet.

   h. Välj Inkrementell för distributionsläget.

   Varning

   I fullständigt distributionsläge tas resurser som finns i resursgruppen men som inte anges i den nya Resource Manager-mallen bort.

   

8. Spara versionspipelinen.

9. Om du vill utlösa en version väljer du Skapa version. I Azure DevOps kan detta automatiseras.

   

Viktigt!

I CI/CD-scenarier måste integreringskörningstypen (IR) i olika miljöer vara densamma. Om du till exempel har en lokalt installerad IR i utvecklingsmiljön måste samma IR också vara av typen self-hosted i andra miljöer, till exempel test och produktion. Om du delar integreringskörningar i flera steg måste du på samma sätt konfigurera integreringskörningarna som länkade lokalt i alla miljöer, till exempel utveckling, test och produktion.

Hämta hemligheter från Azure Key Vault

Om du har hemligheter att skicka in en Azure Resource Manager-mall rekommenderar vi att du använder Azure Key Vault med Azure Pipelines-versionen.

Det finns två sätt att hantera hemligheter:

1. Lägg till hemligheterna i parameterfilen.

   Skapa en kopia av parameterfilen som laddas upp till publiceringsgrenen. Ange värdena för de parametrar som du vill hämta från Key Vault med det här formatet:

   {
       "parameters": {
           "azureSqlReportingDbPassword": {
               "reference": {
                   "keyVault": {
                       "id": "/subscriptions/<subId>/resourceGroups/<resourcegroupId> /providers/Microsoft.KeyVault/vaults/<vault-name> "
                   },
                   "secretName": " < secret - name > "
               }
           }
       }
   }
   

   När du använder den här metoden hämtas hemligheten automatiskt från nyckelvalvet.

   Parameterfilen måste också finnas i publiceringsgrenen.

2. Lägg till en Azure Key Vault-uppgift före Azure Resource Manager-distributionsaktiviteten som beskrivs i föregående avsnitt:

   1. Skapa en ny aktivitet på fliken Uppgifter . Sök efter Azure Key Vault och lägg till det.

   2. I Key Vault-aktiviteten väljer du den prenumeration där du skapade nyckelvalvet. Ange autentiseringsuppgifter om det behövs och välj sedan nyckelvalvet.

   

Bevilja behörigheter till Azure Pipelines-agenten

Azure Key Vault-uppgiften kan misslyckas med ett felmeddelande om nekad åtkomst om rätt behörigheter inte har angetts. Ladda ned loggarna för versionen och leta upp ps1-filen som innehåller kommandot för att ge behörighet till Azure Pipelines-agenten. Du kan köra kommandot direkt. Eller så kan du kopiera huvudnamns-ID:t från filen och lägga till åtkomstprincipen manuellt i Azure-portalen. Get och List är de minsta behörigheter som krävs.

Uppdatera aktiva utlösare

Distributionen kan misslyckas om du försöker uppdatera aktiva utlösare. Om du vill uppdatera aktiva utlösare måste du stoppa dem manuellt och sedan starta om dem efter distributionen. Du kan göra detta med hjälp av en Azure PowerShell-uppgift:

1. På fliken Uppgifter i versionen lägger du till en Azure PowerShell-uppgift . Välj uppgiftsversion 4.*.

2. Välj den prenumeration som din fabrik är i.

3. Välj Skriptfilsökväg som skripttyp. Detta kräver att du sparar PowerShell-skriptet på lagringsplatsen. Följande PowerShell-skript kan användas för att stoppa utlösare:

   $triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName $DataFactoryName -ResourceGroupName $ResourceGroupName
   
   $triggersADF | ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.name -Force }
   

Du kan utföra liknande steg (med Start-AzDataFactoryV2Trigger funktionen) för att starta om utlösarna efter distributionen.

Kommentar

De här stegen ingår redan i för- och efterdistributionsskripten som tillhandahålls av Azure Data Factory-teamet

Manuellt höja upp en Resource Manager-mall för varje miljö

Om du inte kan använda Azure DevOps eller ett annat versionshanteringsverktyg kan du manuellt höja upp en datafabrik med hjälp av en ARM-mall.

1. I listan ARM-mall väljer du Exportera ARM-mall för att exportera Resource Manager-mallen för din datafabrik i utvecklingsmiljön.

   

2. I dina test- och produktionsdatafabriker väljer du Importera ARM-mall. Den här åtgärden tar dig till Azure-portalen, där du kan importera den exporterade mallen. Välj Skapa en egen mall i redigeraren för att öppna Resource Manager-mallredigeraren.

   

3. Välj Läs in fil och välj sedan den genererade Resource Manager-mallen. Det här är filen arm_template.json som finns i zip-filen som exporterades i steg 1.

   

4. I avsnittet Inställningar anger du konfigurationsvärdena, till exempel autentiseringsuppgifter för länkad tjänst. När du är klar väljer du Köp för att distribuera Resource Manager-mallen.

   

Anpassa Azure Resource Manager-mallparametrar

Om utvecklingsfabriken har en associerad git-lagringsplats kan du åsidosätta standardparametrarna för Resource Manager-mallen som genereras genom att publicera eller exportera mallen. Du kanske vill åsidosätta standardparameteriseringsmallen i följande scenarier:

• Du använder automatiserad CI/CD och vill ändra vissa egenskaper under Resource Manager-distributionen, men egenskaperna parametriseras inte som standard.
• Din fabrik är så stor att standardmallen för Resource Manager är ogiltig eftersom den har fler än de högsta tillåtna parametrarna (256).

Om du vill åsidosätta standardparameteriseringsmallen går du till hanteringshubben och väljer Parameteriseringsmall i avsnittet källkontroll. Välj Redigera mall för att öppna kodredigeraren för parameteriseringsmallen.

När du skapar en anpassad parameteriseringsmall skapas en fil med namnet arm-template-parameters-definition.json i rotmappen för git-grenen. Du måste använda det exakta filnamnet.

När du publicerar från samarbetsgrenen läser Data Factory den här filen och använder dess konfiguration för att generera vilka egenskaper som parametriseras. Om ingen fil hittas används standardmallen.

När du exporterar en Resource Manager-mall läser Data Factory den här filen från vilken gren du arbetar med, inte samarbetsgrenen. Du kan skapa eller redigera filen från en privat gren, där du kan testa ändringarna genom att välja Exportera ARM-mall i användargränssnittet. Du kan sedan sammanfoga filen till samarbetsgrenen.

Kommentar

En anpassad parameteriseringsmall ändrar inte parametergränsen för ARM-mallen på 256. Med den kan du välja och minska antalet parametriserade egenskaper.

Syntax för anpassad parameter

Följande är några riktlinjer att följa när du skapar filen med anpassade parametrar, arm-template-parameters-definition.json. Filen består av ett avsnitt för varje entitetstyp: utlösare, pipeline, länkad tjänst, datauppsättning, integrationskörning och dataflöde.

• Ange egenskapssökvägen under relevant entitetstyp.
• Om du anger ett egenskapsnamn till * anger du att du vill parameterisera alla egenskaper under den (endast ned till den första nivån, inte rekursivt). Du kan också ange undantag för den här konfigurationen.
• Om du anger värdet för en egenskap som en sträng anger du att du vill parameterisera egenskapen. Använd formatet <action>:<name>:<stype>.
  • <action> kan vara något av följande tecken:
    • = innebär att behålla det aktuella värdet som standardvärde för parametern.
    • - innebär att du inte behåller standardvärdet för parametern.
    • |är ett specialfall för hemligheter från Azure Key Vault för anslutningssträng eller nycklar.
  • <name> är namnet på parametern. Om den är tom tar den namnet på egenskapen. Om värdet börjar med ett - tecken förkortas namnet. Till exempel AzureStorage1_properties_typeProperties_connectionString skulle förkortas till AzureStorage1_connectionString.
  • <stype> är parametertypen. Om <stype> är tom är stringstandardtypen . Värden som stöds: string, bool, number, objectoch securestring.
• Om du anger en matris i definitionsfilen anger du att den matchande egenskapen i mallen är en matris. Data Factory itererar genom alla objekt i matrisen med hjälp av definitionen som anges i matrisens integreringskörningsobjekt. Det andra objektet, en sträng, blir namnet på egenskapen, som används som namn på parametern för varje iteration.
• En definition kan inte vara specifik för en resursinstans. Alla definitioner gäller för alla resurser av den typen.
• Som standard parametriseras alla säkra strängar, till exempel Key Vault-hemligheter och säkra strängar, till exempel anslutningssträng, nycklar och token.

Länkade mallar

Om du har konfigurerat CI/CD för dina datafabriker kan du överskrida azure Resource Manager-mallgränserna när din fabrik växer sig större. En gräns är till exempel det maximala antalet resurser i en Resource Manager-mall. För att hantera stora fabriker samtidigt som du genererar den fullständiga Resource Manager-mallen för en fabrik genererar Data Factory nu länkade Resource Manager-mallar. Med den här funktionen är hela fabriksnyttolasten uppdelad i flera filer så att du inte begränsas av gränserna.

Om du har konfigurerat Git genereras de länkade mallarna och sparas tillsammans med de fullständiga Resource Manager-mallarna i adf_publish-grenen i en ny mapp med namnet linkedTemplates. De länkade Resource Manager-mallarna består vanligtvis av en huvudmall och en uppsättning underordnade mallar som är länkade till huvudmallen. Den överordnade mallen heter ArmTemplate_master.json och underordnade mallar namnges med mönstret ArmTemplate_0.json, ArmTemplate_1.json och så vidare.

Om du vill använda länkade mallar i stället för den fullständiga Resource Manager-mallen uppdaterar du DIN CI/CD-uppgift så att den pekar på ArmTemplate_master.json i stället för ArmTemplateForFactory.json (den fullständiga Resource Manager-mallen). Resource Manager kräver också att du laddar upp de länkade mallarna till ett lagringskonto så att Azure kan komma åt dem under distributionen.

Produktionsmiljö för snabbkorrigeringar

Om du distribuerar en fabrik till produktion och inser att det finns en bugg som måste åtgärdas direkt, men du inte kan distribuera den aktuella samarbetsgrenen, kan du behöva distribuera en snabbkorrigering. Den här metoden kallas snabbkorrigeringstekniker eller QFE.

1. I Azure DevOps går du till den version som distribuerades till produktion. Hitta den senaste incheckningen som distribuerades.

2. Hämta inchecknings-ID:t för samarbetsgrenen från incheckningsmeddelandet.

3. Skapa en ny snabbkorrigeringsgren från incheckningen.

4. Gå till Azure Data Factory UX och växla till snabbkorrigeringsgrenen.

5. Åtgärda felet med hjälp av Azure Data Factory UX. Testa dina ändringar.

6. När korrigeringen har verifierats väljer du Exportera ARM-mall för att hämta resource manager-mallen för snabbkorrigeringar.

7. Kontrollera den här versionen i publiceringsgrenen manuellt.

8. Om du har konfigurerat versionspipelinen så att den utlöses automatiskt baserat på adf_publish incheckningar startas en ny version automatiskt. Annars köar du en version manuellt.

9. Distribuera snabbkorrigeringsversionen till test- och produktionsfabrikerna. Den här versionen innehåller den tidigare produktionsnyttolasten plus den korrigering som du gjorde i steg 5.

10. Lägg till ändringarna från snabbkorrigeringen i utvecklingsgrenen så att senare versioner inte innehåller samma bugg.

Metodtips för kontinuerlig integrering/kontinuerlig leverans

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 distributionssteget för Resource Manager i CI/CD måste du utföra vissa uppgifter, till exempel att stoppa och starta om utlösare och utföra rensning. Vi rekommenderar att du använder PowerShell-skript före och efter distributionsuppgiften. Datafabriksteamet har angett ett skript som ska användas på dokumentationssidan för Azure Data Factory CI/CD.

• Integreringskörningar och delning. Integreringskörningar ändras inte ofta och liknar alla faser i din CI/CD. Data Factory förväntar sig därför att du har samma namn och typ av integreringskörning i alla faser 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.

• Distribution 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 rekommenderar vi att du behåller 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 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 parameterisera varje anslutningssträng i CI/CD-miljöer eftersom det enda som ändras är nyckelvalvets namn, vilket är en separat parameter.

• Resursnamngivning På grund av begränsningar för ARM-mallar kan problem i distributionen uppstå om dina resurser innehåller blanksteg i namnet. Azure Data Factory-teamet 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".

Fortsätt