Integração e entrega contínuas para uma área de trabalho do Azure Synapse Analytics

A integração contínua (CI) é o processo de automatizar a compilação e a testagem de código sempre que um membro da equipa consolida uma alteração ao controlo de versões. A entrega contínua (CD) é o processo de criação, testagem, configuração e implementação a partir de vários ambientes de teste ou temporários num ambiente de produção.

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

Este artigo descreve como usar um pipeline de liberação do Azure DevOps e Ações do GitHub para automatizar a implantação de um espaço de trabalho do Azure Synapse em vários ambientes.

Pré-requisitos

Para automatizar a implantação de um espaço de trabalho do Azure Synapse em vários ambientes, os seguintes pré-requisitos e configurações devem estar em vigor.

Azure DevOps

• Prepare um projeto de DevOps do Azure para executar o pipeline de versão.
• Conceda a todos os usuários que farão check-in de código acesso básico no nível da organização, para que eles possam ver o repositório.
• Conceda permissão de Proprietário ao repositório Synapse do Azure.
• Certifique-se de ter criado um agente de VM do Azure DevOps auto-hospedado ou use 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 Agente de Implantação do Espaço de Trabalho Synapse do Azure DevOps na organização do Azure DevOps.
• Crie ou nomeie uma conta de serviço existente para que o pipeline seja executado como. Você pode usar um token de acesso pessoal em vez de uma conta de serviço, mas seus pipelines não funcionarão depois que a conta de usuário for excluída.

GitHub

• Crie um repositório GitHub que contenha os artefatos do espaço de trabalho do Azure Synapse e o modelo de espaço de trabalho.
• Certifique-se de que você criou um corredor auto-hospedado ou use um corredor hospedado no GitHub.

Microsoft Entra ID

• 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 ao sistema em sua VM no Azure como agente ou corredor e 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

Nota

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

• O espaço de trabalho "origem" usado para desenvolvimento deve 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 espaço de trabalho em branco para implantar em:

  1. Crie um novo espaço de trabalho do Azure Synapse.
  2. Conceda à entidade de serviço as seguintes permissões para o novo espaço de trabalho Sinapse:
     • Microsoft.Synapse/workspaces/integrationruntimes/write
     • Microsoft.Synapse/workspaces/operationResults/read
     • Microsoft.Synapse/workspaces/read
  3. No espaço de trabalho, não configure a conexão do repositório Git.
  4. No espaço de trabalho do Azure Synapse, vá para Studio>Manage>Access Control. 4. No espaço de trabalho do Azure Synapse, vá para Studio > Manage > Access Control. Atribua o "Synapse Artifact Publisher" à entidade de serviço. Se o pipeline de implantação precisar implantar pontos de extremidade privados gerenciados, atribua o "Synapse Administrator" em vez disso.
  5. Quando você usa serviços vinculados cujas informações de conexão são armazenadas no Cofre de Chaves do Azure, é 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 segredos de produção. Se você seguir essa abordagem, recomendamos que mantenha os mesmos nomes secretos em todos os estágios. Se você mantiver os mesmos nomes secretos, não precisará parametrizar cada cadeia de conexão em ambientes de CI/CD porque a única coisa que muda é o nome do cofre de chaves, que é um parâmetro separado.

Outros pré-requisitos

• Pools de faíscas e tempos de execução de integração auto-hospedados não são criados em uma tarefa de implantação de espaço de trabalho. Se você tiver um serviço vinculado que usa um tempo de execução de integração auto-hospedado, crie manualmente o tempo de execução no novo espaço de trabalho.
• Se os itens no espaço de trabalho de desenvolvimento estiverem anexados aos pools específicos, certifique-se de criar ou parametrizar os mesmos nomes para os pools no espaço de trabalho de destino no arquivo de parâmetros.
• Se os pools SQL provisionados forem pausados 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á como implantar um espaço de trabalho 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 Releases>.

   

3. Selecione Novo pipeline. Se você tiver pipelines existentes, selecione Novo>pipeline de versão.

4. Selecione o modelo de trabalho vazio.

   

5. Em Nome do palco, insira o nome do seu ambiente.

6. Selecione Adicionar artefato e, em seguida, selecione o repositório Git configurado com o Azure Synapse Studio em seu ambiente de desenvolvimento. Selecione o repositório Git no qual você gerencia seus pools e o modelo ARM do espaço de trabalho. Se você usar o GitHub como fonte, crie uma conexão de serviço para sua conta do GitHub e extraia repositórios. Para obter mais informações, consulte Conexões de serviço.

   

7. Selecione a ramificação do modelo ARM do recurso. Para a versão padrão, selecione Mais recente na ramificação padrão.

   

8. Para a ramificação Default de artefatos, selecione a ramificação de publicação do repositório ou outras ramificações não publicadas que incluam artefatos Synapse. Por padrão, a ramificação de publicação é workspace_publish. Para a versão padrão, selecione Mais recente na ramificação padrão.

   

Configurar uma tarefa de estágio para um modelo ARM para criar e atualizar um recurso

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

1. Na vista de palco, selecione Ver tarefas de palco.

   

2. Crie uma nova tarefa. Procure por Implantação de modelo ARM e selecione Adicionar.

3. Na guia Tarefas de implantação, selecione a assinatura, o grupo de recursos e o local do espaço de trabalho. Forneça credenciais, se necessário.

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

5. Em Modelo, selecione o botão de reticências (...). Vá para o modelo ARM do espaço de trabalho.

6. Para Parâmetros do modelo, selecione ... para escolher o arquivo de parâmetros.

   

7. Para Substituir parâmetros do modelo, selecione ..., e insira os valores de parâmetro que você deseja usar para o espaço de trabalho.

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

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

   

Aviso

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

Configurar uma tarefa de estágio para a implantação de artefatos do Azure Synapse

Use a extensão de implantação do espaço de trabalho Synapse para implantar outros itens em seu espaço de trabalho Synapse do Azure. Os itens que você pode implantar incluem conjuntos de dados, scripts e blocos de anotações SQL, definições de trabalho de faísca, tempo de execução de integração, fluxo de dados, credenciais e outros artefatos no espaço de trabalho.

Instalar e adicionar extensão de implantação

1. Procure e obtenha a extensão do 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 Assinatura e foi atribuída como o administrador do espaço de trabalho Synapse para o espaço de trabalho.

4. Para criar uma nova tarefa, procure implantação do espaço de trabalho Synapse e selecione Adicionar.

   

Configurar a tarefa de implantação

A tarefa de implantação suporta 3 tipos de operações, validar apenas, implantar e validar e implantar.

Nota

Esta extensão de implantação do espaço de trabalho não é compatível com versões anteriores. Certifique-se de que a versão mais recente está instalada e utilizada. Você pode ler a nota de versão em visão geralno Azure DevOps e a versão mais recente na ação do GitHub.

Validar é validar os artefatos Synapse na ramificação não publicada com a tarefa e gerar o modelo de espaço de trabalho e o arquivo de modelo de parâmetro. A operação de validação só funciona no pipeline YAML. O arquivo YAML de exemplo é como abaixo:

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

Validar e implantar pode ser usado para implantar diretamente o espaço de trabalho a partir de ramificação não publicada com a pasta raiz do artefato.

Nota

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

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

   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 operação deploy incluem o modelo de espaço de trabalho Synapse e o modelo de parâmetro, que podem ser criados após a publicação na ramificação de publicação do espaço de trabalho ou após a validação. É o mesmo que a 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 do modelo, selecione ... para escolher o arquivo de parâmetros.

4. Selecione uma conexão, um grupo de recursos e um nome para o espaço de trabalho.

5. Ao lado de Substituir parâmetros do modelo, selecione ... . Insira os valores de parâmetro que você deseja usar para o espaço de trabalho, incluindo cadeias de conexão e chaves de conta usadas em seus serviços vinculados. Para obter mais informações, consulte CI/CD no Azure Synapse Analytics.

   

6. A implantação de ponto de extremidade privado gerenciado só é suportada na versão 2.x. certifique-se de selecionar a versão correta e verifique o modelo Implantar pontos de extremidade privados gerenciados.

   

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

   

Importante

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

Criar uma versão para implantação

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

Configurar uma versão no GitHub Actions

Nesta seção, você aprenderá como criar fluxos de trabalho do GitHub usando o GitHub Actions for Azure Synapse workspace deployment.

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

Ficheiro de fluxo de trabalho

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

O arquivo .yml tem duas seções:

Secção	Tarefas
Autenticação	1. Defina uma entidade de serviço. 2. Crie um segredo do GitHub.
Implementar	Implante os artefatos do espaço de trabalho.

Configurar segredos de ações do GitHub

Os segredos das Ações do GitHub são variáveis de ambiente criptografadas. Qualquer pessoa que tenha permissão de Colaborador para este 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. Também pode optar por guardar o ID da subscrição e o ID do inquilino como segredos.

Adicione o seu fluxo de trabalho

No repositório GitHub, vá para Ações.

1. Selecione Configurar seu fluxo de trabalho você mesmo.

2. No arquivo de fluxo de trabalho, exclua tudo após a on: seção. Por exemplo, seu fluxo de trabalho restante pode se parecer com este exemplo:

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

3. Renomeie seu fluxo de trabalho. Na guia Marketplace, procure a ação de implantação do espaço de trabalho Sinapse e adicione a ação.

   

4. Defina os valores necessários e o modelo de espaço de trabalho:

   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. Você está pronto para confirmar suas alterações. Selecione Iniciar confirmação, insira o título e adicione uma descrição (opcional). Em seguida, selecione Confirmar novo arquivo.

   

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

   Nota

   A identidade gerenciada é suportada apenas com VMs autohospedadas no Azure. Certifique-se de definir o corredor como auto-hospedado. Habilite a identidade gerenciada atribuída pelo sistema para sua VM e adicione-a ao Azure Synapse Studio como administrador do Synapse.

Revisar sua implantação

1. No repositório GitHub, vá para Ações.

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

   

Criar parâmetros personalizados no modelo de espaço de trabalho

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, 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 da ramificação do Git. Você deve usar esse nome de arquivo exato. Quando o espaço de trabalho do Azure Synapse publica a partir da ramificação de colaboração ou a tarefa de implantação valida os artefatos em outras ramificações, ele lê esse arquivo e usa sua configuração para gerar os parâmetros. Se o espaço de trabalho do Azure Synapse não encontrar esse arquivo, será usado 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 personalizado:

• 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 para essa configuração.
• Definir o valor de uma propriedade como uma cadeia de caracteres indica que você deseja parametrizar a propriedade. Utilize o formato <action>:<name>:<stype>.
  • <action> pode ser um destes personagens:
    • = significa manter o valor atual como o valor padrão para o parâmetro.
    • - significa não manter o valor padrão para o parâmetro.
    • | é um caso especial para segredos do Cofre de Chaves do Azure para cadeias de conexão ou chaves.
  • <name> é o nome do parâmetro. Se estiver em branco, leva o nome da propriedade. Se o valor começar com um - caractere, o nome será encurtado. Por exemplo, AzureStorage1_properties_typeProperties_connectionString seria encurtado para AzureStorage1_connectionString.
  • <stype> é o tipo de parâmetro. Se <stype> estiver em branco, o tipo padrão será string. Valores suportados: string, , , , objectboolsecureobjectsecurestringinte .array
• Especificar uma matriz no arquivo indica que a propriedade correspondente no modelo é uma matriz. O Azure Synapse itera por todos os objetos na matriz usando a definição especificada. O segundo objeto, uma cadeia de caracteres, torna-se o nome da propriedade, que é usado como o nome para o parâmetro para cada iteração.
• Uma definição não pode ser específica para uma instância de recurso. Qualquer definição aplica-se a todos os recursos desse tipo.
• Por padrão, todas as cadeias de caracteres seguras (como segredos do Cofre da Chave) 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

Aqui está um exemplo de como é uma 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": "="
            }
        }
    }
}

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

notebooks

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

sqlscripts

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

pipelines

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

integrationRuntimes

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

triggers

• Em typeProperties, duas propriedades são parametrizadas:

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

  Nota

  Atualmente, há suporte para um máximo de 50 gatilhos.

linkedServices

• Os serviços vinculados são únicos. Como os serviços vinculados e os conjuntos de dados têm uma ampla variedade de tipos, você pode fornecer personalização específica do tipo. No exemplo anterior, para todos os serviços vinculados do AzureDataLakeStore tipo, um modelo específico é aplicado. Para todos os outros (identificados através do uso do * caractere), um modelo diferente é aplicado.
• A connectionString propriedade é parametrizada como um securestring valor. Ele não tem um valor padrão. O nome do parâmetro é encurtado e sufixo com connectionString.
• A secretAccessKey propriedade é parametrizada como um valor (por exemplo, em um AzureKeyVaultSecret serviço vinculado do Amazon S3). A propriedade é automaticamente parametrizada como um segredo do Cofre de Chaves do Azure 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 explícita de nível * não é necessária. No exemplo anterior, todas as propriedades do conjunto de dados em typeProperties são parametrizadas.

Melhores práticas para CI/CD

Se você estiver usando a integração do Git com seu espaço de trabalho do Azure Synapse e tiver um pipeline de CI/CD que move suas alterações do desenvolvimento para o teste e, em seguida, para a produção, recomendamos estas práticas recomendadas:

• Integre apenas o espaço de trabalho de desenvolvimento com o Git. Se você usar a integração do Git, integre apenas seu espaço de trabalho de desenvolvimento do Azure Synapse com o Git. As alterações nos espaços de trabalho de teste e produção são implantadas via CI/CD e não precisam de integração com o Git.
• Prepare pools antes de migrar artefatos. Se você tiver um script ou bloco de anotações SQL anexado a pools no espaço de trabalho de desenvolvimento, use o mesmo nome para pools em ambientes diferentes.
• Sincronize o controle de versão na infraestrutura como cenários de código. Para gerenciar a 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 de DevOps usa para o código-fonte.
• Analise as práticas recomendadas do Azure Data Factory. Se você usa o Data Factory, consulte as práticas recomendadas para artefatos do Data Factory.

Implementação de artefactos de resolução de problemas

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

No Azure Synapse, ao contrário do Data Factory, os artefatos não são recursos do Gerenciador de Recursos. Você não pode usar a tarefa de implantação de modelo ARM para implantar artefatos do Azure Synapse. Em vez disso, use a tarefa de implantação do espaço de trabalho Synapse para implantar os artefatos e use a tarefa de implantação ARM para implantação de recursos ARM (pools e espaço de trabalho). Enquanto isso, esta tarefa suporta apenas modelos Synapse onde os recursos têm tipo Microsoft.Synapse. E com essa tarefa, os usuários podem implantar alterações de qualquer ramificação automaticamente sem clicar manualmente na publicação no estúdio Synapse. Seguem-se algumas questões frequentemente levantadas.

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

Existe um limite de tamanho de ficheiro no fornecedor do git, por exemplo, no Azure DevOps o tamanho máximo do ficheiro é de 20 MB. Quando o tamanho do arquivo de modelo de espaço de trabalho exceder 20Mb, esse erro acontece quando você publica alterações no Synapse studio, no qual o arquivo de modelo de espaço de trabalho é gerado e sincronizado com o git. Para resolver o problema, você pode usar a tarefa de implantação Synapse com a operação de validação ou validação e implantação para salvar o arquivo de modelo de espaço de trabalho diretamente no agente de pipeline e sem publicação manual no estúdio de sinapse.

2. Erro de token inesperado na versão

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

3. Falha na implantação do tempo de execução da integração

Se você tiver o modelo de espaço de trabalho gerado a partir de um espaço de trabalho gerenciado habilitado para Vnet e tentar implantar em um espaço de trabalho regular ou vice-versa, esse erro acontecerá.

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

O modelo não pode ser analisado o arquivo de modelo. Tente escapar das barras nas costas, por exemplo. \\Test01\Teste

5. Falha ao buscar informações do espaço de trabalho, Não encontrado

As informações do espaço de trabalho de destino não estão configuradas corretamente. Verifique se a conexão de serviço que você criou tem como escopo o grupo de recursos que tem o espaço de trabalho.

6. Falha na exclusão do artefato

A extensão comparará os artefatos presentes na ramificação de publicação com o modelo e, com base na diferença, os excluirá. Por favor, certifique-se de que você não está tentando excluir qualquer artefato que está presente na ramificação de publicação e algum outro artefato tem uma referência ou dependência dele.

8. A implantação falhou com erro: json posição 0

Se você estivesse tentando atualizar manualmente o modelo, esse erro aconteceria. Certifique-se de que não editou manualmente o modelo.

9. A criação ou atualização do documento falhou devido a uma referência inválida

O artefato na sinapse pode ser referenciado por outro. Se você parametrizou um atributo que é referenciado em um artefato, certifique-se de fornecer um valor correto e não nulo para ele

10. Falha ao buscar o status de implantação na implantação do bloco de anotações

O bloco de anotações que você está tentando implantar está anexado a um pool de faíscas no arquivo de modelo de espaço de trabalho, enquanto na implantação o pool não existe no espaço de trabalho de destino. Se você não parametrizar o nome do pool, certifique-se de ter o mesmo nome para os pools entre ambientes.