Integración de Git para el desarrollo de almacén de Fabric

Se aplica a: ✅ Almacén en Microsoft Fabric

Este artículo explica las ventajas de desarrollar y desplegar Fabric Data Warehouse con la integración integrada de Git de Fabric.

Importante

Esta característica se encuentra en versión preliminar.

Al utilizar la integración de Git en Fabric, los equipos pueden aplicar prácticas modernas de control de versiones al desarrollo de almacén. Los desarrolladores pueden aislar cambios en ramas, seguir la evolución del esquema mediante commits, colaborar mediante pull requests y sincronizar actualizaciones entre repositorios Git y espacios de trabajo de Fabric.

Entre los escenarios típicos se incluyen:

  • Desarrollar cambios de esquema de forma segura en ramas y espacios de trabajo
  • Versionado de objetos de almacén en Git
  • Colaborar entre múltiples ramas y espacios de trabajo
  • Promoción de cambios validados entre sucursales
  • Mantener los elementos del espacio de trabajo (almacén y otros) alineados con la fuente de verdad de Git

Para mantener la consistencia, trazabilidad y fiabilidad a lo largo de los ciclos de vida del desarrollo del almacén, necesitas entender estos flujos de trabajo.

Diagrama del ciclo de vida de desarrollo de la integración de Git de Fabric Warehouse.

Cuando conectas un espacio de trabajo de Fabric Data Warehouse a Git, confirmas las definiciones del almacén de datos como un proyecto de base de datos. Este proyecto se convierte en la representación de referencia del esquema del almacén de datos en el sistema de control de versiones y sirve como base para las actividades continuas de desarrollo. En el explorador de control de versiones, el esquema aparece como archivos individuales .sql .

Captura de pantalla del esquema de un almacén de datos en el Explorador de control de código fuente.

Al usar la integración de Git de Fabric y Fabric Data Warehouse, puedes:

Comparación

Durante este proceso de sincronización, Fabric utiliza despliegue de esquema incremental basado en DacFx para aplicar cambios. Este enfoque aplica solo las diferencias de esquema relevantes al almacén, en lugar de actualizar toda la definición del almacén.

La extracción incremental ayuda a reducir los cambios innecesarios en el control de versiones, mantener diferencias de esquema más limpias entre ramas y facilitar flujos de trabajo eficientes de creación de ramas y fusión. Dado que el proceso de extracción es consciente del esquema, también permite una comparación y validación fiable entre el estado del espacio de trabajo y las definiciones rastreadas por Git.

Estandarizar cómo se extraen y almacenan los esquemas de almacén mejora la consistencia entre entornos de desarrollo. Las definiciones de esquemas permanecen estables entre ramas, las diferencias reflejan con mayor precisión los cambios intencionados en el desarrollo, y el control de versiones se convierte en una base fiable para el despliegue, la colaboración y la gestión del ciclo de vida.

El XMLA.json archivo en sí se excluye durante los flujos de trabajo de integración de Git. Fabric excluye este archivo de los commits y actualizaciones para que los metadatos semánticos model por defecto no se almacenen accidentalmente en Git. Al sincronizar un espacio de trabajo desde Git, se ignora XMLA.json, lo que ayuda a evitar conflictos, sobrescrituras no intencionadas y ruido durante el cambio de rama o las actualizaciones desde Git.

Limitaciones en el control de código fuente

  • Las características de seguridad de SQL, como los permisos, requieren un enfoque basado en scripts para exportar y migrar. Considere la posibilidad de usar un script posterior a la implementación en un proyecto de base de datos SQL. Puedes configurar un script post-despliegue en el proyecto con la extensión SQL Database Projects disponible en Visual Studio Code.

  • Las dependencias entre elementos entre almacenes y puntos de conexión de análisis de SQL no se admiten actualmente en los flujos de trabajo de desarrollo. Como resultado, los escenarios que dependen de cambios coordinados entre estos elementos pueden no funcionar de forma fiable.

  • Los scripts previos o post-despliegue y configuraciones adicionales de publicación añadidas directamente al proyecto de base de datos a través de Git no se conservan como parte de los flujos de trabajo de desarrollo. Puede que necesites gestionar estas configuraciones por separado fuera de Fabric Workspace.

  • Las confirmaciones selectivas en el nivel de almacén no se admiten actualmente. Los cambios se confirman a nivel de artículo de almacén en lugar de en niveles de objeto más detallados.

  • La compatibilidad con el control de versiones de los puntos de conexión de análisis de SQL no está disponible actualmente. Esta limitación puede limitar la gestión del ciclo de vida de extremo a extremo cuando las soluciones abarcan tanto almacenes como endpoints de análisis SQL.

Limitaciones de la integración de Git

  • Cuando dos o más elementos de almacén se referencian entre sí, forman una dependencia cíclica. El sistema detecta esta referencia circular durante operaciones de ramificación o sincronización de Git-to-workspace, causando que estas operaciones fallen. Evita dependencias cíclicas entre elementos.
  • Actualmente, no cree un flujo de datos Gen2 con un destino de salida al almacenamiento. Un nuevo elemento denominado DataflowsStagingWarehouse aparece en el repositorio y bloquea la confirmación y actualización desde Git.
  • Las dependencias entre elementos, la secuenciación de elementos y las brechas de sincronización entre el punto de acceso de análisis de SQL y el almacén de datos afectan a los flujos de trabajo de "ramificación a un área de trabajo nueva o existente" y "cambiar a una rama diferente" durante el desarrollo y la integración continua.
  • Si un objeto hace referencia a otro objeto en el mismo almacén de datos mediante una nomenclatura de tres partes (database.schema.object), la confirmación o la actualización desde Git pueden fallar. Para más información y una solución alternativa, consulta Referencias a los propios objetos del almacén usando un nombre de tres partes.
  • Si cambias una columna que tiene definido IDENTITY, confirmar cambios o actualizar desde Git puede fallar hasta que IDENTITY_INSERT esté habilitado en la tabla.
  • Si el repositorio contiene un archivo .sqlproj que fija una versión anterior del SDK Microsoft.Build.Sql, al confirmar cambios o actualizar desde Git puede producirse un error porque el SDK anterior no reconoce la sintaxis más reciente del almacén de datos, como las columnas IDENTITY y CLUSTER BY. Para más información y una solución alternativa, consulta .sqlproj desactualizado en el repositorio Git.
  • Si un objeto hace referencia a dos o más tablas en otro almacén de datos sin calificar cada columna con un alias, la confirmación o la actualización desde Git pueden fallar. Para más información y una solución alternativa, véase Columnas no calificadas en objetos que hacen referencia a dos o más tablas en otro almacén.
  • Si tus scripts hacen referencia a dos o más objetos distintos dentro del mismo esquema de otro almacén de datos y escriben el nombre del esquema con un uso inconsistente de mayúsculas y minúsculas, la confirmación de cambios o la actualización desde Git pueden fallar. Para más información y una solución alternativa, véase Capitalización inconsistente de nombres de esquemas.
  • Pueden producirse errores de columna ambigua cuya lista de candidatos contiene un separador :: al confirmar cambios o actualizar desde Git, incluso cuando no hay una ambigüedad real. Para más información y soluciones alternativas, véase Errores ambiguos en columna con objetos candidatos duplicados.

Escenarios no soportados

Los siguientes procesos de flujo de trabajo de CI/CD no se admiten oficialmente cuando los almacenes de datos en distintos espacios de trabajo tienen intercalaciones diferentes. Aunque estas operaciones se realicen correctamente sin errores, pueden producir errores de metadatos.

En todos estos escenarios, si se produce un error de coincidencia de intercalación, use el script Python scripts/dw-collation-error-update-tmsl/pbi_interactive.py en el repositorio de GitHub del cuadro de herramientas de Fabric para actualizar la intercalación del conjunto de datos (TMSL) de manera que coincida con la intercalación del almacén.

Escenario Description Riesgo
Pipelines de implementación No se admite la promoción del contenido del almacén a través de etapas del flujo de trabajo (por ejemplo, Desarrollo → Prueba → Producción), donde el almacén de destino fue creado con una intercalación diferente a la del origen. La implementación puede realizarse correctamente, pero la ordenación del conjunto de datos no se actualiza para que coincida con la ordenación del almacén de datos de destino.
Bifurcarse en un área de trabajo nueva o existente El uso de la integración de Git para bifurcar desde un área de trabajo existente a una área de trabajo nueva o existente en la que el almacenamiento tiene una intercalación diferente no se admite. El contenido del almacén ha sido sincronizado, pero los metadatos de ordenación no se han reconciliado.
Cambio de rama en un espacio de trabajo No se permite cambiar a una rama asociada a un almacén con una intercalación diferente en un área de trabajo conectada a Git. El contenido sincronizado puede contener suposiciones de intercalación que no coinciden con el almacén de datos actual.
Combinación de cambios entre áreas de trabajo a través de ramas No se admite la combinación de ramas de Git entre áreas de trabajo en las que los repositorios tienen configuraciones de intercalación diferentes. La fusión puede realizarse correctamente a nivel de Git, pero la intercalación del conjunto de datos resultante no refleja la intercalación del almacén de datos de destino.

Paso siguiente

Utiliza la integración de Git para el desarrollo y despliegue de almacén

Contenido relacionado

  • Last updated on