Integración y entrega continuas en un área de trabajo de Azure Synapse Analytics

Artículo
01/30/2024

La integración continua (CI) es el proceso de automatización de la compilación y las pruebas de código cada vez que un miembro del equipo confirma un cambio en el control de versiones. La entrega continua (CD) es el proceso de compilación, pruebas, configuración e implementación desde varios entornos de prueba o ensayo en un entorno de producción.

En un área de trabajo de Azure Synapse Analytics, CI/CD mueve todas las entidades de un entorno (desarrollo, prueba, producción) a otro. La promoción del área de trabajo a otra área de trabajo es un proceso de dos partes. En primer lugar, use una plantilla de Azure Resource Manager para crear o actualizar recursos del área de trabajo (los grupos y el área de trabajo). A continuación, migre artefactos como scripts y cuadernos de SQL, definiciones de trabajos de Spark, canalizaciones, conjuntos de datos y otros artefactos utilizando las herramientas de despliegue del área de trabajo de Synapse en Azure DevOps o en GitHub.

En este artículo se explica cómo usar una canalización de versión de Azure DevOps y Acciones de GitHub para automatizar la implementación de un área de trabajo de Azure Synapse en varios entornos.

Prerrequisitos

Para automatizar la implementación de un área de trabajo de Azure Synapse en varios entornos, deben haberse aplicado los siguientes requisitos previos y configuraciones.

Azure DevOps

Prepare un proyecto de Azure DevOps para ejecutar la canalización de versión.
Conceda a los usuarios que vayan a registrar código acceso Básico en el nivel de organización para que puedan ver el repositorio.
Conceda permiso de propietario al repositorio de Azure Synapse.
Asegúrese de que ha creado un agente de máquina virtual de Azure DevOps auto-hospedado o use un agente hospedado de Azure DevOps.
Conceda permisos para crear una conexión del servicio Azure Resource Manager para el grupo de recursos.
Los administradores de Microsoft Entra deben instalar la extensión Azure DevOps Synapse Workspace Deployment Agent en la organización de Azure DevOps.
Cree o designe una cuenta de servicio existente para que se ejecute la canalización. Puede usar un token de acceso personal, en lugar de una cuenta de servicio, pero las canalizaciones no funcionarán después de que se elimine la cuenta de usuario.

GitHub

Cree un repositorio de GitHub que contenga los artefactos del área de trabajo de Azure Synapse y la plantilla del área de trabajo.
Asegúrese de haber creado un ejecutor auto-hospedado o use uno hospedado en GitHub.

Microsoft Entra ID

En Microsoft Entra ID, si va a usar una entidad de servicio, cree una para usarla en la implementación.
Si va a usar una identidad administrada, habilite la identidad administrada asignada por el sistema en la máquina virtual de Azure como agente o ejecutor y luego agréguela a Azure Synapse Studio como administrador de Synapse.
Use el rol de administrador de Microsoft Entra para llevar a cabo estas acciones.

Azure Synapse Analytics

Nota

Estos requisitos previos se pueden automatizar e implementar mediante la misma canalización, una plantilla de ARM o la CLI de Azure, aunque estos procesos no se explican en este artículo.

El área de trabajo "de origen" que se usa para el desarrollo se debe configurar con un repositorio de Git en Azure Synapse Studio. Para obtener más información, vea Control de código fuente en Azure Synapse Studio.
Configure un área de trabajo en blanco para implementarla:
1. Cree una nueva área de trabajo de Azure Synapse.
2. Conceda a la entidad de servicio los permisos siguientes para la nueva área de trabajo de Synapse:
  - Microsoft.Synapse/workspaces/integrationruntimes/write
  - Microsoft.Synapse/workspaces/operationResults/read
  - Microsoft.Synapse/workspaces/read
3. En el área de trabajo, no configure la conexión del repositorio de Git.
4. En el área de trabajo de Azure Synapse, vaya a Studio>Administrar>Control de acceso. 4. En el área de trabajo de Azure Synapse, vaya a Studio > Administrar > Control de acceso. Asigne el Editor de artefactos de Synapse a la entidad de servicio. Si la canalización de implementación tendrá que implementar puntos de conexión privados administrados, asigne el "Administrador de Synapse" en su lugar.
5. Cuando se usan servicios vinculados cuya información de conexión se almacena en Azure Key Vault, se recomienda mantener almacenes de claves independientes para entornos diferentes. También puede configurar niveles de permisos independientes para cada almacén de claves. Por ejemplo, es posible que no quiera que los miembros del equipo tengan permisos para ver los secretos de producción. Si sigue este enfoque, se recomienda mantener los mismos nombres de secreto en todas las fases. Si mantiene los mismos nombres de secreto, no es necesario parametrizar cada cadena de conexión en los entornos de CI/CD, porque lo único que cambia es el nombre del almacén de claves, que es un parámetro independiente.

Otros requisitos previos

Los grupos de Spark y los entornos de ejecución de integración autohospedados no se crean en una tarea de implementación del área de trabajo. Si tiene un servicio vinculado que use un entorno de ejecución de integración autohospedado, cree este último manualmente en la nueva área de trabajo.
Si los elementos del área de trabajo de desarrollo están asociados a los grupos concretos, asegúrese de crear o parametrizar los mismos nombres para los grupos del área de trabajo de destino en el archivo de parámetros.
Si los grupos de SQL aprovisionados se pausan al intentar realizar la implementación, esta podría no realizarse.

Para obtener más información, vea CI/CD en Azure Synapse Analytics, parte 4: la canalización de versión.

Configuración de una canalización de versión en Azure DevOps

En esta sección va a aprender a implementar un área de trabajo de Azure Synapse en Azure DevOps.

En Azure DevOps, abra el proyecto creado para la versión.
En el menú izquierdo,seleccione Canalizaciones>Versiones.
Selecciona Nueva canalización. Si tiene canalizaciones existentes, seleccione Nueva>Nueva canalización de versión.
Seleccione la plantilla Fase vacía.
En Nombre de la fase, escriba el nombre del entorno.
Seleccione Agregar artefacto y luego seleccione el repositorio de Git configurado con Azure Synapse Studio en el entorno de desarrollo. Seleccione el repositorio de Git en el que administra los grupos y la plantilla de ARM del área de trabajo. Si usa GitHub como origen, cree una conexión de servicio para la cuenta de GitHub y los repositorios de incorporación de cambios. Para obtener más información, vea Conexiones de servicio.
Seleccione la rama de plantilla de ARM del recurso. En Versión predeterminada, seleccione Más reciente de la rama predeterminada.
Para la rama Predeterminada de artefactos, seleccione la rama de publicación del repositorio u otras ramas que no sean de publicación, que incluyen artefactos de Synapse. De manera predeterminada, la rama de publicación es workspace_publish. En Versión predeterminada, seleccione Más reciente de la rama predeterminada.

Configuración de una tarea de fase para una plantilla de ARM a fin de crear y actualizar un recurso

Si tiene una plantilla de ARM que implementa un recurso, como un área de trabajo de Azure Synapse, un grupo de Spark y de SQL o un almacén de claves, agregue una tarea de implementación de Azure Resource Manager para crear o actualizar esos recursos:

En la vista de fase, seleccione Ver tareas de la fase.
Cree una nueva tarea. Busque Implementación de una plantilla de Resource Manager y, después, seleccione Agregar.
En la pestaña Tareas de la implementación, seleccione la suscripción, el grupo de recursos y la ubicación del área de trabajo. Proporcione las credenciales si es necesario.
En Acción, seleccione Creación o actualización del grupo de recursos.
En Plantilla, seleccione el botón de puntos suspensivos ( … ). Vaya a la plantilla de ARM del área de trabajo.
En Parámetros de la plantilla, seleccione … para elegir el archivo de parámetros.
En Reemplazar parámetros de plantilla, seleccione … y escriba los valores de parámetro que quiere usar para el área de trabajo.
En Modo de implementación, seleccione Incremental.
(Opcional) Agregue Azure PowerShell para la concesión y actualice la asignación de roles del área de trabajo. Si usa una canalización de versión para crear un área de trabajo de Azure Synapse, la entidad de servicio de la canalización se agrega como administrador predeterminado del área de trabajo. Puede ejecutar PowerShell para conceder a otras cuentas acceso al área de trabajo.

Advertencia

En el modo de implementación completa, se eliminanlos recursos del grupo de recursos que no están especificados en la nueva plantilla de ARM. Para más información, consulte Modos de implementación de Azure Resource Manager.

Configuración de una tarea de fase para la implementación de artefactos de Azure Synapse

Use la extensión Implementación de área de trabajo de Synapse para implementar otros elementos en el área de trabajo de Azure Synapse. Los elementos que puede implementar incluyen conjuntos de datos, scripts y cuadernos de SQL, definiciones de trabajos de Spark, integration runtime, flujo de datos, credenciales y otros artefactos en el área de trabajo.

Instalación y adición de la extensión de implementación

Busque y obtenga la extensión en Visual Studio Marketplace.
Seleccione la organización de Azure DevOps en la que quiere instalar la extensión.
Asegúrese de que se haya concedido a la entidad de servicio de la canalización de Azure DevOps el permiso de suscripción y de que esté asignada como administrador del área de trabajo de Synapse.
Para crear una nueva tarea, busque Implementación de área de trabajo de Synapse y seleccione Agregar.

Configurar la tarea de implementación

La tarea de implementación admite tres tipos de operaciones, validar solo, implementar y validar e implementar.

Nota:

Esta extensión de implementación de área de trabajo en no es compatible con versiones anteriores. Asegúrese de que la versión más reciente está instalada y usada. Puede leer la nota de la versión en información generalde Azure DevOps y la versión más reciente en la acción de GitHub.

Validar es validar los artefactos de Synapse en una rama que no sea de publicación con la tarea y generar la plantilla del área de trabajo y el archivo de plantilla de parámetros. La operación de validación solo funciona en la canalización de YAML. El archivo YAML de ejemplo es el siguiente:

   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 implementar se puede usar para implementar directamente el área de trabajo desde una rama que no sea de publicación con la carpeta raíz del artefacto.

Nota:

La tarea de implementación debe descargar archivos JS de dependencia de este punto de conexión web.azuresynapse.net cuando el tipo de operación esté seleccionado como Validar o Validar e implementar. Asegúrese de que se permite el punto de conexión web.azuresynapse.net si las directivas de red están habilitadas en la máquina virtual.

La operación de validación e implementación funciona tanto en la canalización clásica como en YAML. El archivo YAML de ejemplo es el siguiente:

   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

Implementar Las entradas de la implementación de la operación incluyen la plantilla del área de trabajo de Synapse y la plantilla de parámetros, que se pueden crear después de la publicación en la rama de publicación del área de trabajo o después de la validación. Es igual que la versión 1.x.

Puede elegir los tipos de operación en función del caso de uso. La siguiente parte es un ejemplo de la implementación.

En la tarea, seleccione el tipo de operación como Implementar.
En la tarea, junto a Plantilla, seleccione … para elegir el archivo de plantilla.
Junto a Parámetros de la plantilla, seleccione … para elegir el archivo de parámetros.
Seleccione una conexión, un grupo de recursos y un nombre para el área de trabajo.
Junto a Reemplazar parámetros de plantilla, seleccione …. Escriba los valores de parámetro que quiere usar para el área de trabajo, incluidas las cadenas de conexión y las claves de cuenta que se usan en los servicios vinculados. Para obtener más información, consulte CI/CD en Azure Synapse Analytics.
La implementación del punto de conexión privado administrado solo se admite en la versión 2.x. Asegúrese de que selecciona la versión correcta y consulte Implementación de puntos de conexión privados administrados en la plantilla.
Para administrar desencadenadores, puede usar el botón de alternancia del desencadenador para detener los desencadenadores antes de la implementación. Y también puede agregar una tarea para reiniciar los desencadenadores después de la tarea de implementación.

Importante

En escenarios de CI/CD, el tipo de entorno de ejecución de integración de otros entornos debe ser el mismo. Por ejemplo, si tiene un entorno de ejecución de integración auto-hospedado en el entorno de desarrollo, el mismo entorno de ejecución de integración debe ser auto-hospedado en otros entornos, como los de prueba y producción. Del mismo modo, si va a compartir entornos de ejecución de integración entre varias fases, tiene que vincularlos y auto-hospedarlos en todos los entornos, como los de desarrollo, prueba y producción.

Creación de una versión para implementación

Después de guardar todos los cambios, puede seleccionar Crear versión para crear manualmente una versión. Para aprender a automatizar la creación de versiones, vea Desencadenadores de versión de Azure DevOps.

Configuración de una versión en Acciones de GitHub

En esta sección va a aprender a crear flujos de trabajo de GitHub mediante Acciones de GitHub para la implementación del área de trabajo de Azure Synapse.

Puede usar Acciones de GitHub para la plantilla de Azure Resource Manager con el fin de automatizar la implementación de una plantilla de ARM en Azure para el área de trabajo y los grupos de proceso.

Archivo de flujo de trabajo

Defina un flujo de trabajo de Acciones de GitHub en un archivo YAML (.yml) en la ruta de acceso /.github/workflows/ del repositorio. La definición contiene los distintos pasos y parámetros que componen el flujo de trabajo.

El archivo .yml tiene dos secciones:

Sección	Tareas
Autenticación	1. Defina una entidad de servicio. 2. Cree un secreto de GitHub.
Implementar	Implemente los artefactos del área de trabajo.

Configuración de secretos de Acciones de GitHub

Los secretos de Acciones de GitHub son variables de entorno cifradas. Cualquier persona que tenga permiso de colaborador en este repositorio puede usar estos secretos para interactuar con Acciones en el repositorio.

En el repositorio de GitHub, seleccione la pestaña Configuración y luego Secretos>Nuevo secreto del repositorio.
Agregue un nuevo secreto para el identificador de cliente, y un nuevo secreto de cliente si usa la entidad de servicio para la implementación. También puede guardar el identificador de suscripción y el identificador de inquilino como secretos.

Agregar el flujo de trabajo

En el repositorio de GitHub, vaya a Acciones.

Seleccione Set up your workflow yourself (Configure el flujo de trabajo usted mismo).
En el archivo de flujo de trabajo, elimine todo lo que aparezca después de la sección on:. Por ejemplo, el flujo de trabajo restante puede tener el aspecto de este ejemplo:
```
name: CI

on:
push:
    branches: [ master ]
pull_request:
    branches: [ master ]
```
Cambie el nombre del flujo de trabajo. En la pestaña Marketplace, busque la acción Implementación de área de trabajo de Synapse y agregue la acción.

Establezca los valores necesarios y la plantilla de área de trabajo:

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'

Ya está listo para confirmar los cambios. Seleccione Iniciar confirmación, escriba el título y agregue una descripción (opcional). Luego seleccione Confirmar nuevo archivo.

El archivo aparece en la carpeta .github/workflows del repositorio.

Nota

La identidad administrada solo se admite en máquinas virtuales auto-hospedadas de Azure. Asegúrese de establecer el ejecutor en auto-hospedado. Habilite la identidad administrada asignada por el sistema de la máquina virtual y agréguela a Azure Synapse Studio como administrador de Synapse.

Revisar la implementación

En el repositorio de GitHub, vaya a Acciones.
Para ver registros detallados de la ejecución del flujo de trabajo,abra el primer resultado:

Creación de parámetros personalizados en la plantilla del área de trabajo

Si usa CI/CD automatizadas y quiere cambiar algunas propiedades durante la implementación pero estas no están parametrizadas de manera predeterminada, puede reemplazar la plantilla de parámetros predeterminada.

Para reemplazar la plantilla de parámetros predeterminada, cree una plantilla de parámetros personalizada de nombre template-parameters-definition.json en la carpeta raíz de la rama de Git. Debe usar este nombre de archivo exacto. Cuando el área de trabajo de Azure Synapse publica desde la rama de colaboración o la tarea de implementación valida los artefactos de otras ramas, lee este archivo y usa su configuración para generar los parámetros. Si el área de trabajo de Azure Synapse no encuentra ese archivo, usa la plantilla de parámetros predeterminada.

Sintaxis de los parámetros personalizados

Puede usar las siguientes instrucciones para crear un archivo de parámetros personalizado:

Escriba la ruta de acceso de la propiedad en el tipo de entidad correspondiente.
El establecimiento de un nombre de propiedad en * indica que quiere parametrizar todas las propiedades que incluye (solo hasta el primer nivel, no de forma recursiva). Puede establecer excepciones a esta configuración.
El establecimiento del valor de una propiedad como una cadena indica que quiere parametrizar la propiedad. Use el formato <action>:<name>:<stype>.
- <action> puede ser uno de estos caracteres:
  - = significa que el valor actual se debe conservar como el predeterminado para el parámetro.
  - - significa que no se debe conservar el valor predeterminado para el parámetro.
  - | es un caso especial para los secretos de Azure Key Vault para cadenas de conexión o claves.
- <name> es el nombre del parámetro. Si está en blanco, toma el nombre de la propiedad. Si el valor empieza por un carácter -, el nombre está abreviado. Por ejemplo, AzureStorage1_properties_typeProperties_connectionString se abreviará a AzureStorage1_connectionString.
- <stype> es el tipo del parámetro. Si <stype> está en blanco, el tipo predeterminado es string. Valores admitidos: string, securestring, int, bool, object, secureobject y array.
Si se ha especificado una matriz en el archivo, significa que la propiedad coincidente de la plantilla es una matriz. Azure Synapse recorre en iteración todos los objetos de la matriz mediante la definición que se ha especificado. El segundo objeto, una cadena, se convierte en el nombre de la propiedad, que se utiliza como el nombre del parámetro para cada iteración.
Una definición no puede ser específica de una instancia de recurso. Cualquier definición se aplica a todos los recursos de ese tipo.
De manera predeterminada, todas las cadenas seguras (como los secretos de Key Vault) y las cadenas seguras (como las cadenas de conexión, las claves y los tokens) están parametrizadas.

Ejemplo de definición de plantilla de parámetros

Este es un ejemplo del aspecto de la definición de una plantilla de parámetros:

{
    "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 es una explicación de cómo se ha construido la plantilla anterior, por tipo de recurso.

notebooks

Cualquier propiedad de la ruta de acceso properties/bigDataPool/referenceName está parametrizada con su valor predeterminado. Puede parametrizar un grupo de Spark asociado para cada archivo del cuaderno.

sqlscripts

En la ruta de acceso properties/content/currentConnection, las propiedades poolName y databaseName están parametrizadas como cadenas sin los valores predeterminados en la plantilla.

pipelines

Cualquier propiedad de la ruta de acceso activities/typeProperties/waitTimeInSeconds está parametrizada. Cualquier actividad en una canalización que tiene una propiedad de nivel de código denominada waitTimeInSeconds (por ejemplo, la actividad Wait) está parametrizada como un número, con un nombre predeterminado. La propiedad no tiene un valor predeterminado en la plantilla de Resource Manager, sino que necesita entrada durante la implementación de Resource Manager.
La propiedad headers (por ejemplo, en una actividad Web) está parametrizada con el tipo object (objeto). La propiedad headers tiene un valor predeterminado que es el mismo que el de la factoría de origen.

integrationRuntimes

Todas las propiedades de la ruta de acceso typeProperties están parametrizadas con sus valores predeterminados correspondientes. Por ejemplo, hay dos propiedades bajo las propiedades de tipo IntegrationRuntimes: computeProperties y ssisProperties. Ambos tipos de propiedades se crean con sus valores predeterminados y tipos (objeto) respectivos.

triggers

En typeProperties hay dos propiedades parametrizadas:
- La propiedad maxConcurrency tiene un valor predeterminado y es de tipo string. El nombre de parámetro predeterminado de la propiedad maxConcurrency es <entityName>_properties_typeProperties_maxConcurrency.
- La propiedad recurrence también está parametrizada. Todas las propiedades bajo la propiedad recurrence están establecidas para parametrizarse como cadenas, con valores predeterminados y nombres de parámetro. Una excepción es la propiedad interval, que está parametrizada como tipo int. El sufijo del nombre del parámetro es <entityName>_properties_typeProperties_recurrence_triggerSuffix. De forma similar, la propiedad freq es una cadena y está parametrizada como una cadena. Sin embargo, la propiedad freq está parametrizada sin un valor predeterminado. El nombre está abreviado y con un sufijo, como <entityName>_freq.
Nota:

Actualmente se admite un máximo de 50 desencadenadores.

linkedServices

Los servicios vinculados son únicos. Dado que los servicios vinculados y los conjuntos de datos tienen una gran variedad de tipos, puede proporcionar una personalización específica de tipo. En el ejemplo anterior, para todos los servicios vinculados de tipo AzureDataLakeStore, se aplica una plantilla específica. Para todos los demás (identificados mediante el carácter *), se aplica otra plantilla.
La propiedad connectionString está parametrizada como un valor securestring. No tiene un valor predeterminado. El nombre de parámetro está abreviado y tiene un sufijo connectionString.
La propiedad secretAccessKey está parametrizada como un valor AzureKeyVaultSecret (por ejemplo, en un servicio vinculado de Amazon S3). La propiedad se parametriza automáticamente como un secreto de Azure Key Vault y se captura desde el almacén de claves configurado. También puede parametrizar el propio almacén de claves.

datasets

Aunque puede personalizar tipos de conjuntos de datos, no se requiere una configuración explícita de *-level. En el ejemplo anterior, todas las propiedades del conjunto de datos de typeProperties están parametrizadas.

Procedimientos recomendados para CI/CD

Si usa la integración de Git con el área de trabajo de Azure Synapse y tiene una canalización de CI/CD que mueve los cambios de desarrollo a pruebas y luego a producción, es aconsejable realizar estos procedimientos recomendados:

Integre solo el área de trabajo de desarrollo con Git. Si usa la integración de Git, integre solo el área de trabajo de Azure Synapse de implementación con Git. Los cambios en las áreas de trabajo de prueba y producción se implementan a través de CI/CD y no se necesita la integración de Git.
Prepare los grupos antes de migrar los artefactos. Si tiene un script de SQL o un cuaderno asociados a grupos del área de trabajo de desarrollo, use el mismo nombre para los grupos de los distintos entornos.
Sincronice el control de versiones de la infraestructura como escenarios de código. Para administrar la infraestructura (redes, máquinas virtuales, equilibradores de carga y topología de conexión) de un modelo descriptivo, use el mismo control de versiones que emplea el equipo de DevOps para el código fuente.
Revise los procedimientos recomendados de Azure Data Factory. Si usa Data Factory, vea los procedimientos recomendados para artefactos de Data Factory.

Solución de problemas de implementación de artefactos

Uso de la tarea de implementación del área de trabajo de Synapse para implementar artefactos de Synapse

En Azure Synapse, a diferencia de Data Factory, los artefactos no son recursos de Resource Manager. No se puede usar la tarea de implementación de plantilla de ARM para implementar artefactos de Azure Synapse. En su lugar, use la tarea de implementación del área de trabajo de Synapse para implementar los artefactos y use la tarea de implementación de ARM para la implementación de recursos de ARM (grupos y áreas de trabajo). Mientras tanto, esta tarea solo admite plantillas de Synapse donde los recursos tienen el tipo Microsoft.Synapse. Además, con esta tarea, los usuarios pueden implementar cambios desde cualquier rama automáticamente sin hacer clic manualmente en la publicación en Synapse Studio. A continuación se muestran algunos problemas que se producen con frecuencia.

1. Error de publicación: el archivo arm del área de trabajo tiene más de 20 MB

Hay una limitación de tamaño de archivo en el proveedor de Git, por ejemplo, en Azure DevOps, el tamaño máximo de archivo es de 20 Mb. Una vez que el tamaño del archivo de plantilla del área de trabajo supera los 20 Mb, este error se produce al publicar cambios en Synapse Studio, en el que se genera y se sincroniza el archivo de plantilla del área de trabajo con Git. Para resolver el problema, puede usar la tarea de implementación de Synapse con la operación de validación o validación e implementación para guardar el archivo de plantilla del área de trabajo directamente en el agente de la canalización y sin publicar manualmente en Synapse Studio.

2. Error de token inesperado en la versión

Si el archivo de parámetros tiene valores de parámetro sin escape, la canalización de versión no puede analizar el archivo y genera un error unexpected token. Se sugiere reemplazar los parámetros o usar Key Vault para recuperar los valores de parámetro. También puede usar caracteres de escape doble para resolver el problema.

3. Error en la implementación de entorno de ejecución de integración

Si tiene la plantilla de área de trabajo generada a partir de un área de trabajo habilitada para la red virtual administrada e intenta realizar la implementación en un área de trabajo normal o viceversa, este error se produce.

4. Carácter inesperado encontrado al analizar el valor

La plantilla no se puede analizar el archivo de plantilla. Intente escapar de las barras diagonales inversas, por ejemplo. \\Test01\Test

5. No se pudo capturar la información del área de trabajo, No se encontró

La información del área de trabajo de destino no está configurada correctamente. Asegúrese de que la conexión de servicio que ha creado tiene como ámbito el grupo de recursos que tiene el área de trabajo.

6. Error de eliminación de artefactos

La extensión comparará los artefactos presentes en la rama de publicación con la plantilla y en función de la diferencia que los eliminará. Asegúrese de que no está intentando eliminar ningún artefacto que esté presente en la rama de publicación y que algún otro artefacto tenga una referencia o dependencia en él.

8. Error de implementación: posición json 0

Si intentaba actualizar manualmente la plantilla, se produciría este error. Asegúrese de que no ha editado manualmente la plantilla.

9. Error al crear o actualizar los documentos debido a una referencia no válida

Otro puede hacer referencia al artefacto en synapse. Si ha parametrizado un atributo al que se hace referencia en un artefacto, asegúrese de proporcionar un valor correcto y distinto de NULL.

10. No se pudo capturar el estado de implementación en la implementación del cuaderno

El cuaderno que intenta implementar está asociado a un grupo de Spark en el archivo de plantilla del área de trabajo, mientras que en la implementación el grupo no existe en el área de trabajo de destino. Si no parametriza el nombre del grupo, asegúrese de que tiene el mismo nombre para los grupos entre entornos.