Kontinuerlig integrering och leverans för en Azure Synapse Analytics-arbetsyta

Kontinuerlig integrering (CI) är en process för att automatisera skapande och testning av kod varje gång en teammedlem checkar in ändringar till versionskontrollen. Kontinuerlig leverans (CD) är en process för att skapa, testa, konfigurera och distribuera från flera test- eller mellanlagringsmiljöer till en produktionsmiljö.

I en Azure Synapse Analytics-arbetsyta flyttar kontinuerlig integrering/leverans (CI/CD) alla entiteter från en miljö (utveckling, test, produktion) till en annan miljö. Att upphöja din arbetsyta till en annan arbetsyta är en process som består av två delar. Använd först en Azure Resource Manager-mall (ARM-mall) för att skapa eller uppdatera arbetsyteresurser (pooler och arbetsyta). Migrera sedan artefakter som SQL-skript och notebook-filer, Spark-jobbdefinitioner, pipelines, datauppsättningar och andra artefakter med hjälp av Synapse Workspace Deployment-verktyg i Azure DevOps eller på GitHub.

Den här artikeln beskriver hur du använder en Azure DevOps-versionspipeline och GitHub Actions för att automatisera distributionen av en Azure Synapse-arbetsyta till flera miljöer.

Förutsättningar

För att automatisera distributionen av en Azure Synapse-arbetsyta till flera miljöer måste följande krav och konfigurationer finnas på plats. Observera att du kan välja att använda antingen Azure DevOps eller GitHub, enligt dina inställningar eller befintliga inställningar.

Azure DevOps

Om du använder Azure DevOps:

• Förbered ett Azure DevOps-projekt för att köra versionspipelinen.
• Ge alla användare som checkar in kod Grundläggande åtkomst på organisationsnivå, så att de kan se lagringsplatsen.
• Bevilja ägarbehörighet till Azure Synapse-lagringsplatsen.
• Kontrollera att du har skapat en lokalt installerad Azure DevOps VM-agent eller använder en Värdbaserad Azure DevOps-agent.
• Bevilja behörigheter för att skapa en Azure Resource Manager-tjänstanslutning för resursgruppen.
• En Microsoft Entra-administratör måste installera azure DevOps Synapse Workspace Deployment Agent-tillägget i Azure DevOps-organisationen.
• Skapa eller nominera ett befintligt tjänstkonto som pipelinen ska köras som. Du kan använda en personlig åtkomsttoken i stället för ett tjänstkonto, men dina pipelines fungerar inte när användarkontot har tagits bort.

GitHub

Om du använder GitHub:

• Skapa en GitHub-lagringsplats som innehåller artefakterna för Azure Synapse-arbetsytan och arbetsytemallen.
• Kontrollera att du har skapat en lokalt installerad löpare eller använda en GitHub-värdbaserad löpare.

Microsoft Entra ID

• Om du använder ett huvudnamn för tjänsten i Microsoft Entra-ID skapar du ett huvudnamn för tjänsten som ska användas för distribution.
• Om du använder en hanterad identitet aktiverar du den systemtilldelade hanterade identiteten på den virtuella datorn i Azure som agent eller löpare och lägger sedan till den i Azure Synapse Studio som Synapse-administratör.
• Använd administratörsrollen Microsoft Entra för att slutföra dessa åtgärder.

Azure Synapse Analytics

• Den källarbetsyta som används för utveckling måste konfigureras med en Git-lagringsplats i Azure Synapse Studio. Mer information finns i Källkontroll i Azure Synapse Studio.

• Konfigurera en tom arbetsyta som ska distribueras till:

  1. Skapa en ny Azure Synapse-arbetsyta.
  2. Ge tjänstens huvudnamn följande behörigheter till den nya Synapse-arbetsytan:
     • Microsoft.Synapse/workspaces/integrationruntimes/write
     • Microsoft.Synapse/workspaces/operationResults/read
     • Microsoft.Synapse/workspaces/read
  3. Konfigurera inte Git-lagringsplatsanslutningen på arbetsytan.
  4. På Azure Synapse-arbetsytan går du till Studio>Hantera>åtkomstkontroll. 4. På Azure Synapse-arbetsytan går du till Studio > Hantera > åtkomstkontroll. Tilldela "Synapse Artifact Publisher" till tjänstens huvudnamn. Om distributionspipelinen behöver distribuera hanterade privata slutpunkter tilldelar du i stället "Synapse-administratören".
  5. 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 niska veze i CI/CD-miljöer eftersom det enda som ändras är nyckelvalvets namn, vilket är en separat parameter.

Övriga förutsättningar

• Spark-pooler och lokalt installerade integrationskörningar skapas inte i en arbetsytedistributionsuppgift. Om du har en länkad tjänst som använder en lokalt installerad integrationskörning skapar du körningen manuellt på den nya arbetsytan.
• Om objekten i utvecklingsarbetsytan är kopplade till de specifika poolerna kontrollerar du att du skapar eller parameteriserar samma namn för poolerna på målarbetsytan i parameterfilen.
• Om dina etablerade SQL-pooler pausas när du försöker distribuera kan distributionen misslyckas.

Mer information finns i CI/CD i Azure Synapse Analytics del 4 – versionspipelinen.

Konfigurera en versionspipeline i Azure DevOps

I det här avsnittet får du lära dig hur du distribuerar en Azure Synapse-arbetsyta i Azure DevOps.

1. Öppna projektet du skapade för versionen i Azure DevOps.

2. På den vänstra menyn väljer du Pipelines-versioner>.

   

3. Välj Ny pipeline. Om du har befintliga pipelines väljer du Ny>ny versionspipeline.

4. Välj mallen Tomt jobb .

   

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

6. Välj Lägg till artefakt och välj sedan den Git-lagringsplats som har konfigurerats med Azure Synapse Studio i utvecklingsmiljön. Välj den Git-lagringsplats där du hanterar arm-mallen för dina pooler och arbetsytor. Om du använder GitHub som källa skapar du en tjänstanslutning för ditt GitHub-konto och hämtar lagringsplatser. Mer information finns i tjänstanslutningar.

   

7. Välj resursens ARM-mallgren. Som Standardversion väljer du Senaste från standardgrenen.

   

8. För artefaktens standardgren väljer du lagringsplatsens publiceringsgren eller andra icke-publiceringsgrenar som innehåller Synapse-artefakter. Som standard är workspace_publishpubliceringsgrenen . Som Standardversion väljer du Senaste från standardgrenen.

   

Konfigurera en fasaktivitet för en ARM-mall för att skapa och uppdatera en resurs

Om du har en ARM-mall som distribuerar en resurs, till exempel en Azure Synapse-arbetsyta, en Spark- och SQL-pool eller ett nyckelvalv, lägger du till en Azure Resource Manager-distributionsuppgift för att skapa eller uppdatera dessa resurser:

1. I fasvyn väljer du Visa stegaktiviteter.

   

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

3. På fliken Distributionsuppgifter väljer du prenumeration, resursgrupp och plats för arbetsytan. Ange autentiseringsuppgifter om det behövs.

4. För Åtgärd väljer du Skapa eller uppdatera resursgrupp.

5. För Mall väljer du ellipsknappen (...). Gå till ARM-mallen för arbetsytan.

6. För Mallparametrar väljer du ... för att välja parameterfilen.

   

7. För Åsidosätt mallparametrar väljer du ...och anger sedan de parametervärden som du vill använda för arbetsytan.

8. För Distributionsläge väljer du Inkrementell.

9. (Valfritt) Lägg till Azure PowerShell för tilldelningen och uppdatera rolltilldelningen för arbetsytan. Om du använder en versionspipeline för att skapa en Azure Synapse-arbetsyta läggs pipelinens tjänsthuvudnamn till som standardadministratör för arbetsytan. Du kan köra PowerShell för att ge andra konton åtkomst till arbetsytan.

   

Konfigurera en fasaktivitet för distribution av Azure Synapse-artefakter

Använd distributionstillägget för Synapse-arbetsytan för att distribuera andra objekt på din Azure Synapse-arbetsyta. Objekt som du kan distribuera är datauppsättningar, SQL-skript och notebook-filer, spark-jobbdefinitioner, integreringskörning, dataflöde, autentiseringsuppgifter och andra artefakter på arbetsytan.

Installera och lägga till distributionstillägg

1. Sök efter och hämta tillägget från Visual Studio Marketplace.

   

2. Välj den Azure DevOps-organisation där du vill installera tillägget.

   

3. Kontrollera att Azure DevOps-pipelinens tjänsthuvudnamn har beviljats prenumerationsbehörigheten och har tilldelats som Administratör för Synapse-arbetsytan för arbetsytan.

4. Om du vill skapa en ny uppgift söker du efter Distribution av Synapse-arbetsyta och väljer sedan Lägg till.

   

Konfigurera distributionsuppgiften

Distributionsuppgiften stöder tre typer av åtgärder, validerar endast, distribuerar och verifierar och distribuerar.

Verifiera är att verifiera Synapse-artefakterna i en gren som inte publiceras med uppgiften och generera arbetsytemallen och parametermallfilen. Valideringsåtgärden fungerar bara i YAML-pipelinen. YAML-exempelfilen är som nedan:

   pool:
     vmImage: ubuntu-latest

   resources:
     repositories:
     - repository: <repository name>
       type: git
       name: <name>
       ref: <user/collaboration branch>

   steps:
     - checkout: <name>
     - task: Synapse workspace deployment@2
       continueOnError: true    
       inputs:
         operation: 'validate'
         ArtifactsFolder: '$(System.DefaultWorkingDirectory)/ArtifactFolder'
         TargetWorkspaceName: '<target workspace name>'    

Verifiera och distribuera kan användas för att direkt distribuera arbetsytan från en gren som inte publiceras med artefaktrotmappen.

Verifierings- och distributionsåtgärden fungerar i både den klassiska pipelinen och YAML-pipelinen. YAML-exempelfilen är som nedan:

   pool:
     vmImage: ubuntu-latest

   resources:
     repositories:
     - repository: <repository name>
       type: git
       name: <name>
       ref: <user/collaboration branch>

   steps:
     - checkout: <name>
     - task: Synapse workspace deployment@2
       continueOnError: true    
       inputs:
         operation: 'validateDeploy'
         ArtifactsFolder: '$(System.DefaultWorkingDirectory)/ArtifactFolder'
         TargetWorkspaceName: 'target workspace name'
         azureSubscription: 'target Azure resource manager connection name'
         ResourceGroupName: 'target workspace resource group'
         DeleteArtifactsNotInTemplate: true
         OverrideArmParameters: >
           -key1 value1
           -key2 value2

Distribuera Indata för åtgärden distribuera inkluderar Synapse-arbetsytemallen och parametermallen, som kan skapas efter publicering i arbetsytans publiceringsgren eller efter valideringen. Det är samma som version 1.x.

Du kan välja åtgärdstyper baserat på användningsfallet. Följande del är ett exempel på distributionen.

1. I uppgiften väljer du åtgärdstypen som Distribuera.

   

2. I uppgiften bredvid Mall väljer du ... för att välja mallfilen.

3. Bredvid Mallparametrar väljer du ... för att välja parameterfilen.

4. Välj en anslutning, resursgrupp och ett namn för arbetsytan.

5. Bredvid Åsidosätt mallparametrar väljer du ... . Ange de parametervärden som du vill använda för arbetsytan, inklusive niska veze och kontonycklar som används i dina länkade tjänster. Mer information finns i CI/CD i Azure Synapse Analytics.

   

6. Distributionen av den hanterade privata slutpunkten stöds endast i version 2.x. Kontrollera att du väljer rätt version och kontrollera distribuera hanterade privata slutpunkter i mallen.

   

7. Om du vill hantera utlösare kan du använda utlösarväxlingsknappen för att stoppa utlösarna före distributionen. Och du kan också lägga till en uppgift för att starta om utlösarna efter distributionsaktiviteten.

   

Skapa en version för distribution

När du har sparat alla ändringar kan du välja Skapa version för att manuellt skapa en version. Information om hur du automatiserar skapandet av versioner finns i Azure DevOps-versionsutlösare.

Konfigurera en version i GitHub Actions

I det här avsnittet får du lära dig hur du skapar GitHub-arbetsflöden med hjälp av GitHub Actions för azure Synapse-arbetsytedistribution.

Du kan använda Mallen GitHub Actions för Azure Resource Manager för att automatisera distributionen av en ARM-mall till Azure för arbetsytan och beräkningspoolerna.

Arbetsflödesfil

Definiera ett GitHub Actions-arbetsflöde i en YAML-fil (.yml) i sökvägen /.github/workflows/ i lagringsplatsen. Definitionen innehåller de olika steg och parametrar som utgör arbetsflödet.

Filen .yml innehåller två avsnitt:

Konfigurera GitHub Actions-hemligheter

GitHub Actions-hemligheter är miljövariabler som är krypterade. Alla som har behörighet som medarbetare till den här lagringsplatsen kan använda dessa hemligheter för att interagera med Åtgärder på lagringsplatsen.

1. På GitHub-lagringsplatsen väljer du fliken Inställningar och sedan Hemligheter>Ny lagringsplatshemlighet.

   

2. Lägg till en ny hemlighet för klient-ID:t och lägg till en ny klienthemlighet om du använder tjänstens huvudnamn för distribution. Du kan också välja att spara prenumerations-ID och klient-ID som hemligheter.

Lägg till arbetsflödet

Gå till Åtgärder på din GitHub-lagringsplats.

1. Välj Konfigurera arbetsflödet själv.

2. Ta bort allt efter on: avsnittet i arbetsflödesfilen. Ditt återstående arbetsflöde kan till exempel se ut som i det här exemplet:

   name: CI
   
   on:
   push:
       branches: [ master ]
   pull_request:
       branches: [ master ]
   

3. Byt namn på arbetsflödet. På fliken Marketplace söker du efter distributionsåtgärden för Synapse-arbetsytan och lägger sedan till åtgärden.

   

4. Ange nödvändiga värden och arbetsytemallen:

   name: workspace deployment
   
   on:
       push:
           branches: [ publish_branch ]
   jobs:
       release:
           # You also can use the self-hosted runners.
           runs-on: windows-latest
           steps:
           # Checks out your repository under $GITHUB_WORKSPACE, so your job can access it.
           - uses: actions/checkout@v2
           - uses: azure/synapse-workspace-deployment@release-1.0
           with:
             TargetWorkspaceName: 'target workspace name'
             TemplateFile: './path of the TemplateForWorkspace.json'
             ParametersFile: './path of the TemplateParametersForWorkspace.json'
             OverrideArmParameters: './path of the parameters.yaml'
             environment: 'Azure Public'
             resourceGroup: 'target workspace resource group'
             clientId: ${{secrets.CLIENTID}}
             clientSecret:  ${{secrets.CLIENTSECRET}}
             subscriptionId: 'subscriptionId of the target workspace'
             tenantId: 'tenantId'
             DeleteArtifactsNotInTemplate: 'true'
             managedIdentity: 'False'
   

5. Du är redo att genomföra ändringarna. Välj Starta incheckning, ange rubriken och lägg sedan till en beskrivning (valfritt). Välj sedan Checka in ny fil.

   

   Filen visas i mappen .github/workflows på lagringsplatsen.

   Kommentar

   Hanterad identitet stöds endast med lokala virtuella datorer i Azure. Se till att ställa in löparen på egen värd. Aktivera den systemtilldelade hanterade identiteten för den virtuella datorn och lägg till den i Azure Synapse Studio som Synapse-administratör.

Granska distributionen

1. Gå till Åtgärder på din GitHub-lagringsplats.

2. Om du vill se detaljerade loggar för arbetsflödets körning öppnar du det första resultatet:

   

Skapa anpassade parametrar i arbetsytemallen

Om du använder automatiserad CI/CD och vill ändra vissa egenskaper under distributionen, men egenskaperna inte parametriseras som standard, kan du åsidosätta standardparametermallen.

Om du vill åsidosätta standardparametermallen skapar du en anpassad parametermall med namnet template-parameters-definition.json i rotmappen för git-grenen. Du måste använda exakt det här filnamnet. När Azure Synapse-arbetsytan publicerar från samarbetsgrenen eller distributionsuppgiften validerar artefakterna i andra grenar, läser den den här filen och använder dess konfiguration för att generera parametrarna. Om Azure Synapse-arbetsytan inte hittar filen används standardparametermallen.

Syntax för anpassad parameter

Du kan använda följande riktlinjer för att skapa en anpassad parameterfil:

• Ange egenskapssökvägen under relevant entitetstyp.
• Om du anger ett egenskapsnamn till * anger du att du vill parameterisera alla egenskaper under egenskapen (endast ned till den första nivån, inte rekursivt). Du kan ange undantag till 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 niska veze 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, securestring, int, bool, secureobject objectoch array.
• Om du anger en matris i filen anger du att den matchande egenskapen i mallen är en matris. Azure Synapse itererar genom alla objekt i matrisen med hjälp av den definition som har angetts. 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 niska veze, nycklar och token).

Exempel på parametermalldefinition

Här är ett exempel på hur en parametermallsdefinition ser ut:

{
    "Microsoft.Synapse/workspaces/notebooks": {
        "properties": {
            "bigDataPool": {
                "referenceName": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/sqlscripts": {
        "properties": {
            "content": {
                "currentConnection": {
                    "*": "-"
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/pipelines": {
        "properties": {
            "activities": [{
                "typeProperties": {
                    "waitTimeInSeconds": "-::int",
                    "headers": "=::object",
                    "activities": [
                        {
                            "typeProperties": {
                                "url": "-:-webUrl:string"
                            }
                        }
                    ]
                }
            }]
        }
    },
    "Microsoft.Synapse/workspaces/integrationRuntimes": {
        "properties": {
            "typeProperties": {
                "*": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/triggers": {
        "properties": {
            "typeProperties": {
                "recurrence": {
                    "*": "=",
                    "interval": "=:triggerSuffix:int",
                    "frequency": "=:-freq"
                },
                "maxConcurrency": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/linkedServices": {
        "*": {
            "properties": {
                "typeProperties": {
                    "accountName": "=",
                    "username": "=",
                    "connectionString": "|:-connectionString:secureString",
                    "secretAccessKey": "|"
                }
            }
        },
        "AzureDataLakeStore": {
            "properties": {
                "typeProperties": {
                    "dataLakeStoreUri": "="
                }
            }
        },
        "AzureKeyVault": {
            "properties": {
                "typeProperties": {
                    "baseUrl": "|:baseUrl:secureString"
                },
                "parameters": {
                    "KeyVaultURL": {
                        "type": "=",
                        "defaultValue": "|:defaultValue:secureString"
                    }
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/datasets": {
        "*": {
            "properties": {
                "typeProperties": {
                    "folderPath": "=",
                    "fileName": "="
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/credentials" : {
        "properties": {
            "typeProperties": {
                "resourceId": "="
            }
        }
    }
}

Här är en förklaring av hur den föregående mallen skapas efter resurstyp.

notebooks

• Alla egenskaper i properties/bigDataPool/referenceName sökvägen parametriseras med dess standardvärde. Du kan parametrisera en bifogad Spark-pool för varje notebook-fil.

sqlscripts

• properties/content/currentConnection I sökvägen parametriseras både poolName egenskaperna och databaseName som strängar utan standardvärdena i mallen.

pipelines

• Alla egenskaper i activities/typeProperties/waitTimeInSeconds sökvägen parametriseras. Alla aktiviteter i en pipeline som har en kodnivåegenskap med namnet waitTimeInSeconds (till exempel Wait aktiviteten) parametriseras som ett tal med ett standardnamn. Egenskapen har inget standardvärde i Resource Manager-mallen. I stället krävs indata för egenskapen under Resource Manager-distributionen.
• Egenskapen headers (till exempel i en Web aktivitet) parametriseras med object typen (objekt). Egenskapen headers har ett standardvärde som är samma värde som källfabriken.

integrationRuntimes

• Alla egenskaper i typeProperties sökvägen parametriseras med respektive standardvärden. Två egenskaper finns till exempel under IntegrationRuntimes typegenskaper: computeProperties och ssisProperties. Båda egenskapstyperna skapas med respektive standardvärden och typer (objekt).

triggers

• Under typePropertiesparameteriseras två egenskaper:

  • Egenskapen maxConcurrency har ett standardvärde och är typen string . Standardparameternamnet för maxConcurrency egenskapen är <entityName>_properties_typeProperties_maxConcurrency.
  • Egenskapen recurrence är också parametriserad. Alla egenskaper under egenskapen recurrence är inställda på att parametriseras som strängar, med standardvärden och parameternamn. Ett undantag är egenskapen interval som parameteriseras som int typen . Parameternamnet är suffixet med <entityName>_properties_typeProperties_recurrence_triggerSuffix. På samma sätt är egenskapen freq en sträng och parametriseras som en sträng. Egenskapen parametriseras dock freq utan ett standardvärde. Namnet förkortas och suffixet, till exempel <entityName>_freq.

  Kommentar

  För närvarande stöds högst 50 utlösare.

linkedServices

• Länkade tjänster är unika. Eftersom länkade tjänster och datauppsättningar har en mängd olika typer kan du tillhandahålla typspecifik anpassning. I föregående exempel tillämpas en specifik mall för alla länkade tjänster av typen AzureDataLakeStore . För alla andra (identifieras med hjälp av * tecknet) tillämpas en annan mall.
• Egenskapen connectionString parameteriseras som ett securestring värde. Det har inget standardvärde. Parameternamnet förkortas och suffixet med connectionString.
• Egenskapen secretAccessKey parametriseras som ett AzureKeyVaultSecret värde (till exempel i en länkad Amazon S3-tjänst). Egenskapen parametriseras automatiskt som en Azure Key Vault-hemlighet och hämtas från det konfigurerade nyckelvalvet. Du kan också parametrisera själva nyckelvalvet.

datasets

• Även om du kan anpassa typer i datauppsättningar krävs ingen explicit konfiguration på *-nivå. I föregående exempel parametriseras alla datauppsättningsegenskaper under typeProperties .

Regelverk för CI/CD

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

• Integrera endast utvecklingsarbetsytan med Git. Om du använder Git-integrering integrerar du bara din Azure Synapse-arbetsyta för utveckling med Git. Ändringar i test- och produktionsarbetsytor distribueras via CI/CD och behöver inte Git-integrering.
• Förbered pooler innan du migrerar artefakter. Om du har ett SQL-skript eller en notebook-fil som är kopplad till pooler på utvecklingsarbetsytan använder du samma namn för pooler i olika miljöer.
• Synkronisera versionshantering i infrastrukturen som kodscenarier. Om du vill hantera infrastruktur (nätverk, virtuella datorer, lastbalanserare och anslutningstopologi) i en beskrivande modell använder du samma versionshantering som DevOps-teamet använder för källkod.
• Granska metodtipsen för Azure Data Factory. Om du använder Data Factory läser du metodtipsen för Data Factory-artefakter.

Felsöka distribution av artefakter

Använda distributionsuppgiften för Synapse-arbetsytan för att distribuera Synapse-artefakter

I Azure Synapse, till skillnad från i Data Factory, är artefakter inte Resource Manager-resurser. Du kan inte använda ARM-malldistributionsuppgiften för att distribuera Azure Synapse-artefakter. Använd i stället distributionsaktiviteten för Synapse-arbetsytan för att distribuera artefakterna och använda ARM-distributionsaktiviteten för ARM-resurser (pooler och arbetsyta). Under tiden stöder den här uppgiften endast Synapse-mallar där resurser har typen Microsoft.Synapse. Med den här uppgiften kan användarna distribuera ändringar från alla grenar automatiskt utan att manuellt klicka på publicera i Synapse Studio. Följande är några vanliga problem.

1. Publiceringen misslyckades: arbetsytans armfil är mer än 20 MB

Det finns en filstorleksbegränsning i git-providern. Till exempel är den maximala filstorleken 20 MB i Azure DevOps. När storleken på arbetsytans mallfil överskrider 20 Mb uppstår det här felet när du publicerar ändringar i Synapse Studio, där arbetsytemallfilen genereras och synkroniseras till git. För att lösa problemet kan du använda Synapse-distributionsuppgiften med verifierings- eller verifierings- och distributionsåtgärden för att spara arbetsytemallfilen direkt i pipelineagenten och utan manuell publicering i Synapse Studio.

2. Oväntat tokenfel i versionen

Om parameterfilen har parametervärden som inte är undantagna kan versionspipelinen inte parsa filen och genererar ett unexpected token fel. Vi rekommenderar att du åsidosätter parametrar eller använder Key Vault för att hämta parametervärden. Du kan också använda dubbla escape-tecken för att lösa problemet.

3. Integreringskörningsdistributionen misslyckades

Om du har skapat arbetsytemallen från en hanterad Vnet-aktiverad arbetsyta och försöker distribuera till en vanlig arbetsyta eller vice versa uppstår det här felet.

4. Oväntat tecken påträffades vid parsning av värde

Mallen kan inte parsas mallfilen. Försök genom att fly tillbaka snedstreck, t.ex. \\Test01\Test

5. Det gick inte att hämta information om arbetsytan, hittades inte

Målarbetsytans information är inte korrekt konfigurerad. Kontrollera att tjänstanslutningen som du har skapat är begränsad till den resursgrupp som har arbetsytan.

6. Artefaktborttagningen misslyckades

Tillägget jämför artefakterna som finns i publiceringsgrenen med mallen och baserat på skillnaden tas de bort. Kontrollera att du inte försöker ta bort någon artefakt som finns i publiceringsgrenen och att någon annan artefakt har en referens eller ett beroende av den.

8. Distributionen misslyckades med fel: json-position 0

Om du försökte uppdatera mallen manuellt skulle det här felet inträffa. Kontrollera att du inte har redigerat mallen manuellt.

9. Det gick inte att skapa eller uppdatera dokumentet på grund av en ogiltig referens

Artefakten i synapsen kan refereras till av en annan. Om du har parametriserat ett attribut som refereras till i en artefakt måste du ange rätt och icke null-värde för det

10. Det gick inte att hämta distributionsstatusen i notebook-distributionen

Anteckningsboken som du försöker distribuera är kopplad till en Spark-pool i arbetsytans mallfil, medan poolen inte finns i målarbetsytan i distributionen. Om du inte parameteriserar poolnamnet kontrollerar du att poolerna har samma namn mellan miljöer.