Integração e entrega contínuas para um workspace do Azure Synapse Analytics

A CI (integração contínua) é o processo de automatizar o build e o teste do código sempre que um membro da equipe confirma uma alteração no controle de versão. A CD (entrega contínua) é o processo de criação, teste, configuração e implantação de vários ambientes de teste ou de preparação em um ambiente de produção.

Em um workspace do Azure Synapse Analytics, a CI/CD move todas as entidades de um ambiente (desenvolvimento, teste, produção) para outro ambiente. Promover seu workspace para outro workspace é um processo de duas partes. Primeiro, use um modelo do ARM (Azure Resource Manager) para criar ou atualizar recursos do workspace (pools e workspace). Então migre artefatos como scripts e notebooks do SQL, definições de trabalho do Spark, pipelines, conjuntos de dados e outros artefatos usando ferramentas de Implantação do Workspace do Synapse no Azure DevOps ou no GitHub.

Este artigo descreve como usar um pipeline de lançamento do Azure DevOps e do GitHub Actions para automatizar a implantação de um workspace do Azure Synapse em vários ambientes.

Pré-requisitos

Para automatizar a implantação de um workspace do Azure Synapse em vários ambientes, os pré-requisitos e configurações a seguir devem ser implantados.

Azure DevOps

• Prepare um projeto do Azure DevOps para executar o pipeline de lançamento.
• Conceda o acesso Básico a todos os usuários que verificarão o código no nível da organização para que eles possam ver o repositório.
• Conceda permissão de Proprietário ao repositório do Azure Synapse.
• Verifique se você criou um agente de VM do Azure DevOps auto-hospedado ou se está usando um agente hospedado do Azure DevOps.
• Conceda permissões para criar uma conexão de serviço do Azure Resource Manager para o grupo de recursos.
• Um administrador do Microsoft Entra deve instalar a extensão do Deployment Agent do Workspace do Synapse do Azure DevOps na organização do Azure DevOps.
• Crie ou nomeie uma conta de serviço existente na qual o pipeline será executado. Você pode usar um token de acesso pessoal em vez de uma conta de serviço, mas os seus pipelines não funcionarão depois que a conta de usuário for excluída.

GitHub

• Crie um GitHub que contém os artefatos do workspace do Azure Synapse e o modelo de workspace.
• Certifique-se de ter criado um executor auto-hospedado ou use um executor hospedado no GitHub.

ID do Microsoft Entra

• Se você estiver usando uma entidade de serviço, no Microsoft Entra ID, crie uma entidade de serviço para usar na implantação.
• Se você estiver usando uma identidade gerenciada, habilite a identidade gerenciada atribuída pelo sistema em sua VM no Azure como o agente ou o executor em seguida, adicione-a ao Azure Synapse Studio como administrador do Synapse.
• Use a função de administrador do Microsoft Entra para concluir essas ações.

Azure Synapse Analytics

Observação

Você pode automatizar e implantar esses pré-requisitos usando o mesmo pipeline, um modelo do ARM ou a CLI do Azure, mas esses processos não estão descritos neste artigo.

• O workspace de “origem” usado para desenvolvimento precisa ser configurado com um repositório Git no Azure Synapse Studio. Para obter mais informações, consulte Controle do código-fonte no Azure Synapse Studio.

• Configure um workspace em branco no qual implantar:

  1. Crie um workspace do Azure Synapse.
  2. Conceda à entidade de serviço as seguintes permissões no novo workspace do Synapse:
     • Microsoft.Synapse/workspaces/integrationruntimes/write
     • Microsoft.Synapse/workspaces/operationResults/read
     • Microsoft.Synapse/workspaces/read
  3. No workspace, não configure a conexão do repositório Git.
  4. No workspace do Azure Synapse, acesse Studio>Gerenciar>Controle de acesso. 4. No workspace do Azure Synapse, acesse Studio > Gerenciar > Controle de Acesso. Atribua o “Editor de Artefatos do Synapse” à entidade de serviço. Se o pipeline de implantação precisar implantar pontos de extremidade privados gerenciados, atribua o “Administrador do Synapse”.
  5. Quando você usa serviços vinculados cujas informações de conexão são armazenadas no Azure Key Vault, é recomendável manter cofres de chaves separados para ambientes diferentes. Você também pode configurar níveis de permissão separados para cada cofre de chaves. Por exemplo, talvez você não queira que os membros da sua equipe tenham permissões para os segredos de produção. Se você seguir essa abordagem, recomendamos que você mantenha os mesmos nomes de segredo em todas as fases. Se você mantiver os mesmos nomes de segredo, não precisará parametrizar cada cadeia de conexão em ambientes de CI/CD porque a única coisa que é alterada é o nome do cofre de chaves, que é um parâmetro separado.

Outros pré-requisitos

• Os pools do Spark e os runtimes de integração auto-hospedada não são criados em uma tarefa de implantação do workspace. Se você tiver um serviço vinculado que usa um runtime de integração auto-hospedada, crie o runtime manualmente no novo workspace.
• Se os itens no workspace de desenvolvimento estão anexados com os pools específicos, certifique-se de criar ou parametrizar os mesmos nomes dos pools no workspace de destino no arquivo de parâmetro.
• Se os pools de SQL provisionados estiverem em pausa quando você tentar implantar, a implantação poderá falhar.

Para obter mais informações, consulte CI/CD no Azure Synapse Analytics parte 4 – O pipeline de lançamento.

Configurar um pipeline de lançamento no Azure DevOps

Nesta seção, você aprenderá a implantar um workspace do Azure Synapse no Azure DevOps.

1. No Azure DevOps, abra o projeto que você criou para a versão.

2. No menu à esquerda, selecione Pipelines>Lançamentos.

   

3. Selecione Novo pipeline. Se você tiver pipelines existentes, selecione Novo>Novo pipeline de lançamento.

4. Selecione o modelo Trabalho vazio.

   

5. No Nome da fase, insira o nome do seu ambiente.

6. Selecione Adicionar artefato e escolha o repositório do Git configurado com o Azure Synapse Studio no seu ambiente de desenvolvimento. Selecione o repositório Git no qual você gerencia seus pools e o modelo ARM do workspace. Se você usar o GitHub como a origem, crie uma conexão de serviço para sua conta do GitHub e repositórios de pull. Para mais informações, consulte as conexões de serviço.

   

7. Selecione o branch de modelo do ARM do recurso. Para a Versão padrão, selecione Mais recente do branch padrão.

   

8. Para o Branch padrão de artefatos, selecione o repositório branch de publicação ou outros branches não de publicação que incluem artefatos do Synapse. Por padrão, o branch de publicação é workspace_publish. Para a Versão padrão, selecione Mais recente do branch padrão.

   

Configurar uma tarefa de preparo para um modelo do ARM para criar e atualizar um recurso

Se você tiver um modelo do ARM para implantar um recurso, como um workspace do Azure Synapse, um pool do Spark e um pool de SQL ou um cofre de chaves, adicione uma tarefa de implantação do Azure Resource Manager para criar ou atualizar esses recursos:

1. No modo de exibição de fase, selecione Exibir tarefas da fase.

   

2. Crie uma tarefa. Pesquise Implantação de Modelo do ARM e Adicionar.

3. Na guia de implantação Tarefas, selecione a assinatura, o grupo de recursos e um local para o workspace. Forneça as credenciais, se necessário.

4. Para Ação, selecione Criar ou atualizar um grupo de recursos.

5. Para Modelo, selecione o botão de reticências ( … ). Vá para o modelo do ARM do workspace.

6. Em Parâmetros de modelo, selecione … para escolher o arquivo de parâmetros.

   

7. Para Substituir parâmetros do modelo, selecione … e, em seguida, insira os valores de parâmetro que você deseja usar para o workspace.

8. Para Modo de implantação, selecione Incremental.

9. (Opcional) Adicione Azure PowerShell para a atribuição de função de workspace de concessão e atualização. Se você usar um pipeline de lançamento para criar um workspace do Azure Synapse, a entidade de serviço do pipeline será adicionada como administrador do workspace padrão. Você pode executar o PowerShell para conceder a outras contas acesso ao workspace.

   

Aviso

No modo de implantação completo, os recursos no grupo de recursos que não forem especificados no modelo do ARM serão excluídos. Para obter mais informações, confira Modos de implantação do Azure Resource Manager.

Configurar uma tarefa de preparo para a implantação de artefatos do Azure Synapse

Use a extensão de implantação do workspace do Synapse para implantar outros itens em seu workspace do Azure Synapse. Os itens que você pode implantar incluem conjuntos de dados, scripts SQL e notebooks, definições de trabalho do Spark, runtime de integração, fluxo de dados, credenciais e outros artefatos no workspace.

Instalar e adicionar extensão de implantação

1. Pesquise e receba a extensão Visual Studio Marketplace.

   

2. Selecione a organização do Azure DevOps na qual você deseja instalar a extensão.

   

3. Verifique se a entidade de serviço do pipeline do Azure DevOps recebeu a permissão de assinatura e foi atribuída como administradora do workspace do Synapse para o workspace.

4. Para criar uma nova tarefa, procure a implantação do workspace do Synapse e, em seguida, selecione Adicionar.

   

Configure a tarefa de implantação

A tarefa de implantação dá suporte a três tipos de operações: somente validar, implantar e validar e somente implantar.

Observação

Essa extensão de implantação de workspace não é compatível com versões anteriores. Verifique se a versão mais recente está instalada e é usada. Você pode ler a nota sobre a versão na visão geralno Azure DevOps e na versão mais recente na ação do GitHub.

Validar é validar os artefatos do Synapse no branch não de publicação com a tarefa e gerar o modelo de workspace e o arquivo de modelo de parâmetro. A operação de validação só funciona no pipeline YAML. O arquivo YAML de exemplo é o seguinte:

   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>'    

A validação e a implantação podem ser usadas para implantar diretamente o workspace do branch não de publicação com a pasta raiz do artefato.

Observação

A tarefa de implantação precisa baixar arquivos JS de dependência do ponto de extremidade web.azuresynapse.net quando o tipo de operação é selecionado como Validar ou Validar e implantar. Verifique se o ponto de extremidade web.azuresynapse.net é permitido se as políticas de rede estiverem habilitadas na VM.

A operação de validação e implantação funciona tanto no pipeline clássico quanto no YAML. O arquivo YAML de exemplo é o seguinte:

   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

Implantar As entradas da implantação da operação incluem o modelo de workspace do Synapse e o modelo de parâmetro, que pode ser criado após a publicação no branch de publicação do workspace ou após a validação. É igual à versão 1.x.

Você pode escolher os tipos de operação com base no caso de uso. A parte a seguir é um exemplo da implantação.

1. Na tarefa, selecione o tipo de operação como Implantar.

   

2. Na tarefa, ao lado de Modelo, selecione … para escolher o arquivo de modelo.

3. Ao lado de Parâmetros de modelo, selecione … para escolher o arquivo de parâmetros.

4. Selecione uma conexão, um grupo de recursos e um nome para o workspace.

5. Ao lado de Substituir parâmetros de modelo, selecione …. Insira os valores de parâmetro que você deseja usar para o workspace, incluindo cadeias de conexão e chaves de conta que são usadas nos seus serviços vinculados. Para saber mais, confira CI/CD no Azure Synapse Analytics.

   

6. Só há suporte para a implantação do ponto de extremidade privado gerenciado na versão 2.x. Verifique se você selecionou a versão correta e confira Implantar pontos de extremidade privados gerenciados no modelo.

   

7. Para gerenciar os gatilhos, você pode usar a alternância de gatilho para interromper os gatilhos antes da implantação. Adicione também uma tarefa para reiniciar os gatilhos após a tarefa de implantação.

   

Importante

Em cenários de CI/CD, o tipo de runtime de integração em ambientes diferentes deve ser o mesmo. Por exemplo, se você tiver um runtime de integração auto-hospedado no ambiente de desenvolvimento, o mesmo runtime de integração deve ser do tipo auto-hospedado em outros ambientes, como teste e produção. Da mesma forma, se você estiver compartilhando runtimes de integração em várias fases, os runtimes de integração devem ser vinculados e auto-hospedados em todos os ambientes, como desenvolvimento, teste e produção.

Criar uma versão para a implantação

Depois de salvar todas as alterações, você pode selecionar Criar versão para criar uma versão manualmente. Para saber como automatizar uma criação de versão, consulte Gatilhos de versão do Azure DevOps.

Configurar uma versão no GitHub Actions

Nesta seção, você aprenderá a criar fluxos de trabalho do GitHub usando o GitHub Actions para a implantação do workspace do Azure Synapse.

Você pode usar o GitHub Actions para modelo do Azure Resource Manager e automatizar a implantação de um modelo do ARM no Azure para o workspace e os pools de computação.

Arquivo de fluxo de trabalho

Defina um fluxo de trabalho do GitHub Actions em um arquivo YAML (.yml) no caminho /.github/workflows/ em seu repositório. Essa definição contém as várias etapas e os parâmetros que compõem o fluxo de trabalho.

O arquivo .yml tem duas seções:

Seção	Tarefas
Autenticação	1. Definir uma entidade de serviço. 2. Criar um segredo do GitHub.
Implantar	Implante os artefatos do workspace.

Configurar os segredos do GitHub Actions

Os segredos do GitHub Actions são variáveis de ambiente criptografadas. Qualquer pessoa que tenha a permissão de colaborador para esse repositório pode usar esses segredos para interagir com ações no repositório.

1. No repositório GitHub, selecione a guia Configurações e, em seguida, selecione Segredos>Novo segredo do repositório.

   

2. Adicione um novo segredo para a ID do cliente e adicione um novo segredo do cliente se você usar a entidade de serviço para implantação. Você também pode optar por salvar a ID da assinatura e a ID do locatário como segredos.

Adicionar seu fluxo de trabalho

No seu repositório do GitHub, acesse Ações.

1. Selecione Configurar seu fluxo de trabalho por conta própria.

2. No arquivo do fluxo de trabalho, exclua tudo depois da seção on:. Por exemplo, seu fluxo de trabalho restante poderá ter a aparência deste exemplo:

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

3. Renomeie seu fluxo de trabalho. Na guia Marketplace, pesquise a ação de implantação do workspace do Synapse e, em seguida, adicione a ação.

   

4. Configure os valores necessários e o modelo de workspace:

   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. Agora você está pronto para fazer commit de suas alterações. Selecione Iniciar commit, insira o título e, em seguida, adicione uma descrição (opcional). Em seguida, selecione Fazer commit de novo arquivo.

   

   O arquivo aparece na pasta .github/workflows em seu repositório.

   Observação

   A identidade gerenciada só tem suporte com VMs auto-hospedadas no Azure. Certifique-se de definir o executor como auto-hospedado. Habilite a identidade gerenciada atribuída pelo sistema para sua VM e adicione ao Azure Synapse Studio como administrador do Synapse.

Examinar sua implantação

1. No seu repositório do GitHub, acesse Ações.

2. Para ver os logs detalhados da execução do fluxo de trabalho, abra o primeiro resultado:

   

Criar parâmetros personalizados no modelo de workspace

Se você usar CI/CD automatizado e quiser alterar algumas propriedades durante a implantação, mas as propriedades não forem parametrizadas por padrão, você poderá substituir o modelo de parâmetro padrão.

Para substituir o modelo de parâmetro padrão, crie um modelo de parâmetro personalizado chamado template-parameters-definition.json na pasta raiz do Git branch. Você deve usar esse nome de arquivo exato. Quando o workspace do Azure Synapse publica no branch de colaboração ou a tarefa de implantação valida os artefatos em outros branches, ele lê esse arquivo e usa a configuração dele para gerar os parâmetros. Se o workspace do Azure Synapse não encontrar esse arquivo, ele usará o modelo de parâmetro padrão.

Sintaxe do parâmetro personalizado

Você pode usar as seguintes diretrizes para criar um arquivo de parâmetros personalizados:

• Insira o caminho da propriedade sob o tipo de entidade relevante.
• Definir um nome de propriedade como * indica que você deseja parametrizar todas as propriedades sob a propriedade (somente até o primeiro nível, não recursivamente). Você pode definir exceções a essa configuração.
• Definir o valor de uma propriedade como uma cadeia de caracteres indica que você deseja parametrizar a propriedade. Use o formato <action>:<name>:<stype>.
  • <action> pode ser um desses caracteres:
    • = significa manter o valor atual como o valor padrão do parâmetro.
    • - significa não manter o valor padrão do parâmetro.
    • | é um caso especial para segredos do Azure Key Vault para cadeias de conexão ou chaves.
  • <name> é o nome do parâmetro. Se estiver em branco, será usado o nome da propriedade. Se o valor começar com um caractere -, o nome será abreviado. Por exemplo, AzureStorage1_properties_typeProperties_connectionString seria abreviado como AzureStorage1_connectionString.
  • <stype> é o tipo de parâmetro. Se <stype> estiver em branco, o tipo padrão será string. Valores com suporte: string, securestring, int, bool, object, secureobject e array.
• Especificar uma matriz no arquivo indica que a propriedade correspondente no modelo é uma matriz. O Azure Synapse itera todos os objetos na matriz usando a definição especificada. O segundo objeto, uma cadeia de caracteres, torna-se o nome da propriedade, que é usada como o nome do parâmetro para cada iteração.
• Uma definição não pode ser específica a uma instância de recurso. Qualquer definição se aplica a todos os recursos desse tipo.
• Por padrão, todas as cadeias de caracteres seguras (como segredos do Key Vault) e cadeias de caracteres seguras (como cadeias de conexão, chaves e tokens) são parametrizadas.

Exemplo de definição de modelo de parâmetro

Veja um exemplo de como é a definição de modelo de parâmetro:

{
    "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": "="
            }
        }
    }
}

Esta é uma explicação de como o modelo anterior é construído, por tipo de recurso.

notebooks

• Qualquer propriedade no caminho properties/bigDataPool/referenceName é parametrizada com seu valor padrão. Você pode parametrizar um pool do Spark anexado para cada arquivo de notebook.

sqlscripts

• No caminho properties/content/currentConnection, as propriedades poolName e databaseName são parametrizadas como cadeias de caracteres sem os valores padrão no modelo.

pipelines

• Qualquer propriedade no caminho activities/typeProperties/waitTimeInSeconds é parametrizada. Qualquer atividade em um pipeline que tenha uma propriedade de nível de código chamada waitTimeInSeconds (por exemplo, a atividade Wait) é parametrizada como um número, com um nome padrão. A propriedade não terá um valor padrão no modelo do Resource Manager. Em vez disso, a propriedade será necessária durante a implantação do Resource Manager.
• A propriedade headers (por exemplo, em uma atividade Web) é parametrizada com o tipo object (Objeto). A propriedade headers tem um valor padrão que é o mesmo valor do alocador de origem.

integrationRuntimes

• Todas as propriedades no caminho typeProperties são parametrizadas com os respectivos valores padrão. Por exemplo, duas propriedades nas propriedades do tipo IntegrationRuntimes: computeProperties e ssisProperties. Ambos os tipos de propriedade são criados com os respectivos valores e tipos padrão (Object).

triggers

• Em typeProperties, duas propriedades são parametrizadas:

  • A propriedade maxConcurrency tem um valor padrão e é o tipo string. O nome do parâmetro padrão da propriedade maxConcurrency é <entityName>_properties_typeProperties_maxConcurrency.
  • A propriedade recurrence também é parametrizada. Todas as propriedades na propriedade recurrence são definidas para serem parametrizadas como cadeias de caracteres, com valores padrão e nomes de parâmetro. Uma exceção é a propriedade interval, parametrizada como tipo int. O nome do parâmetro tem sufixo <entityName>_properties_typeProperties_recurrence_triggerSuffix. Da mesma forma, a propriedade freq é uma cadeia de caracteres e é parametrizada como uma cadeia de caracteres. No entanto, a propriedade freq é parametrizada sem um valor padrão. O nome é abreviado e sufixado, como <entityName>_freq.

  Observação

  Atualmente, há suporte para, no máximo, 50 gatilhos.

linkedServices

• Os serviços vinculados são exclusivos. Como os serviços vinculados e os conjuntos de linhas têm uma ampla gama de tipos, você pode fornecer uma personalização específica de tipo. Neste exemplo anterior, para todos os serviços vinculados do tipo AzureDataLakeStore, um modelo específico será aplicado. Para todos os outros (identificados por meio do uso do caractere *), um modelo diferente é aplicado.
• A propriedade connectionString é parametrizada como um valor securestring. Ela não tem um valor padrão. O nome do parâmetro é abreviado e tem sufixo com connectionString.
• A propriedade secretAccessKey é parametrizada como um valor AzureKeyVaultSecret (por exemplo, em um serviço vinculado do Amazon S3). A propriedade é parametrizada automaticamente como um segredo do Azure Key Vault e buscada no cofre de chaves configurado. Você também pode parametrizar o próprio cofre de chaves.

datasets

• Embora você possa personalizar tipos em conjuntos de dados, uma configuração de nível explícito * não é necessária. No exemplo anterior, todas as propriedades de conjunto de dados em typeProperties são parametrizadas.

Práticas recomendadas para CI/CD

Se você está usando a integração do Git ao seu workspace do Azure Synapse e tem um pipeline de CI/CD que migra as suas alterações do desenvolvimento para o teste e para a produção, recomendamos estas práticas recomendadas:

• Integre apenas o workspace de desenvolvimento ao Git. Se você usar a integração do Git, integre somente seu workspace do Azure Synapse de desenvolvimento ao Git. As alterações nos workspaces de teste e produção são implantadas por meio de CI/CD e não precisam de integração com o git.
• Prepare pools antes de migrar artefatos. Se você tiver um script SQL ou um notebook anexado a pools no workspace de desenvolvimento, use o mesmo nome de pools em ambientes diferentes.
• Sincronize o controle de versão na infraestrutura como cenários de código. Para gerenciar infraestrutura (redes, máquinas virtuais, balanceadores de carga e topologia de conexão) em um modelo descritivo, use o mesmo controle de versão que a equipe do DevOps usa para o código-fonte.
• Revise as melhores práticas do Azure Data Factory. Se você usar o Data Factory, consulte as melhores práticas para artefatos do Data Factory.

Solucionar problemas de implantação de artefatos

Use a tarefa de implantação do espaço de trabalho Synapse para implantar artefatos Synapse

No Azure Synapse, ao contrário do Azure Data Factory, os artefatos não são recursos do Azure Resource Manager. Você não pode usar a tarefa de implantação de modelo do ARM para implantar artefatos do Azure Synapse. Em vez disso, use a tarefa de implantação do workspace do Synapse para implantar os artefatos e use a tarefa de implantação do ARM para a implantação de recursos do ARM (pools e workspace). Enquanto isso, essa tarefa só dá suporte a modelos do Synapse em que os recursos têm o tipo Microsoft.Synapse. E com essa tarefa, os usuários podem implantar alterações de quaisquer branches automaticamente sem clicar manualmente na publicação no Synapse Studio. Veja a seguir algumas questões frequentemente levantadas.

1. Falha na publicação: o arquivo do braço do workspace tem mais de 20 MB

Há uma limitação de tamanho de arquivo no provedor git, por exemplo, no Azure DevOps, o tamanho máximo do arquivo é 20 Mb. Depois que o tamanho do arquivo de modelo de workspace excede 20Mb, esse erro ocorre quando você publica alterações no Synapse Studio, em que o arquivo de modelo de workspace é gerado e sincronizado com o git. Para resolver o problema, você pode usar a tarefa de implantação do Synapse com a operação validar ou validar e implantar para salvar o arquivo de modelo de workspace diretamente no agente de pipeline e sem publicação manual no Synapse Studio.

2. Erro de token inesperado na versão

Se o arquivo de parâmetro tiver valores de parâmetro que não foram escapados, o pipeline de lançamento não analisará o arquivo e gerará um erro unexpected token. Sugerimos que você substitua parâmetros ou use o Key Vault para recuperar valores de parâmetro. Você também pode usar caracteres de escape duplos para resolver o problema.

3. Falha na implantação do runtime de integração

Se você tiver o modelo de workspace gerado de um workspace habilitado para Vnet gerenciada e tentar implantar em um workspace regular ou vice-versa, esse erro ocorrerá.

4. Caractere inesperado encontrado durante a análise do valor

O modelo não pode ser analisado no arquivo de modelo. Tente escapar das barras invertidas, por exemplo, \\Test01\Test

5. Falha ao buscar informações do workspace, Não encontrado

As informações do workspace de destino não estão configuradas corretamente. Verifique se a conexão de serviço que você criou está no escopo do grupo de recursos que possui o workspace.

6. Falha na exclusão do artefato

A extensão comparará os artefatos presentes no branch de publicação com o modelo e, com base na diferença, os excluirá. Verifique se você não está tentando excluir nenhum artefato que esteja presente no branch de publicação e que algum outro artefato tenha uma referência ou dependência nele.

8. Falha na implantação com erro: posição json 0

Se você estivesse tentando atualizar manualmente o modelo, esse erro aconteceria. Verifique se você não editou manualmente o modelo.

9. Falha na criação ou atualização do documento devido à referência inválida

O artefato no synapse pode ser referenciado por outro. Se você tiver parametrizado um atributo que é referenciado em um artefato, certifique-se de fornecer valor correto e não nulo a ele

10. Falha ao buscar o status de implantação na implantação do notebook

O notebook que você está tentando implantar está anexado a um pool do Spark no arquivo de modelo de workspace, enquanto na implantação o pool não existe no workspace de destino. Se você não parametrizar o nome do pool, certifique-se de ter o mesmo nome para os pools entre os ambientes.