Control de código fuente, CI/CD y ALM para el agente de datos de Fabric (versión preliminar)

En este artículo se describe cómo administrar agentes de datos de Fabric mediante canalizaciones de implementación e integración de Git como parte de las funcionalidades de Administración del ciclo de vida de aplicaciones (ALM) de Microsoft Fabric. Aprenderá a conectar un área de trabajo a un repositorio de Git. También aprenderá a cómo realizar el seguimiento y la versión de las configuraciones del agente de datos. Por último, aprenderá a promover actualizaciones en entornos de desarrollo, pruebas y producción. Las canalizaciones de implementación e integración de Git permiten la integración continua y la implementación continua (CI/CD) de los cambios del agente de datos, lo que permite probar y promover actualizaciones automáticamente como parte del flujo de trabajo de ALM. El control de código fuente de los agentes de datos de Fabric está actualmente en versión preliminar.

Puede emplear dos enfoques complementarios para apoyar ALM en agentes de datos de Fabric.

• Integración de Git: sincronice un área de trabajo completa con un repositorio de Git (Azure DevOps o GitHub como proveedor de Git) para habilitar el control de versiones, la colaboración a través de ramas y el seguimiento del historial de elementos individuales, incluidos los agentes de datos de Fabric.
• Canalizaciones de implementación: promueva el contenido entre áreas de trabajo independientes que representan fases de desarrollo, prueba y producción mediante canalizaciones integradas.

Estas funcionalidades proporcionan compatibilidad completa con ALM para agentes de datos de Fabric.

Importante

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

Prerrequisitos

• Una capacidad de Tejido F2 o superior de pago, o una capacidad de Power BI Premium por capacidad (P1 o superior) con Microsoft Fabric habilitado
• La configuración del inquilino del agente de datos de Fabric está habilitada.
• El procesamiento entre regiones geográficas para la inteligencia artificial está habilitado.
• El almacenamiento entre regiones geográficas para la inteligencia artificial está habilitado.
• Al menos uno de ellos, con datos: un almacén, un lakehouse, uno o varios modelos semánticos de Power BI, una base de datos KQL o una ontología.
• Modelos semánticos de Power BI a través del conmutador de inquilino de puntos de conexión XMLA está habilitado para orígenes de datos del modelo semántico de Power BI.

Integración con Git

La integración de Git de Microsoft Fabric sincroniza un área de trabajo de Fabric con un repositorio de Git, lo que le permite usar los procesos de desarrollo, las herramientas y los procedimientos recomendados existentes directamente en la plataforma Fabric. Admite Azure DevOps y GitHub y está disponible en el nivel de área de trabajo. Al confirmar los cambios de Fabric, incluidas las actualizaciones de la configuración del agente de datos, esos cambios se guardan como archivos en el repositorio de Git conectado. Sus funcionalidades clave incluyen:

• Copia de seguridad completa y control de versiones de los elementos del área de trabajo
• La estructura de carpetas de Git refleja la estructura del área de trabajo.
• Las configuraciones del agente de datos (selección de esquemas, instrucciones de IA, instrucciones de origen de datos, consultas de ejemplo) se almacenan en archivos estructurados en carpetas dedicadas.
• Capacidad de ver las diferencias, revisar el historial y revertir a estados anteriores a través del historial para distintos elementos del área de trabajo, incluidos los agentes de datos
• Colaboración basada en ramas (ramas de características, principal)

Para obtener más información sobre el proceso de integración de Git, puede consultar los siguientes recursos.

• ¿Qué es la integración de Git de Microsoft Fabric?
• Conceptos básicos de la integración de Git
• Introducción a la integración de Git

Configuración de una conexión al control de código fuente

Puede conectar el área de trabajo de Fabric a un repositorio de Git desde la página Configuración del área de trabajo. Esta conexión le permite confirmar y sincronizar los cambios directamente desde Fabric.

1. Consulte Introducción a la integración de Git para obtener pasos detallados para conectarse a un repositorio de Git en Azure DevOps o GitHub.

2. Después de conectarse al repositorio de Git, los elementos del área de trabajo, incluidos los agentes de datos de Fabric, aparecen en el panel Control de código fuente. En la barra de estado de la parte inferior izquierda, puede ver el nombre de la rama conectada, la hora de la última sincronización y el identificador de confirmación de Git.

3. El repositorio git vinculado muestra una estructura de carpetas que representa los elementos del área de trabajo, incluidos los agentes de datos de Fabric y sus archivos de configuración. Cada agente de datos se almacena en su propia carpeta, lo que le permite revisar los cambios, realizar un seguimiento del historial de versiones y usar flujos de trabajo de Git, como la creación de solicitudes de incorporación de cambios para combinar actualizaciones en la rama principal.

4. Al realizar modificaciones en el agente de datos de Fabric en un área de trabajo conectada a Git, se detectan los cambios y el estado del agente de datos en el panel Control de código fuente cambia a Cambios no confirmados. Estas modificaciones pueden incluir:

   • Cambiar la selección del esquema.
   • Actualizar las instrucciones de IA o las instrucciones del origen de datos.
   • Edición de consultas de ejemplo.
   • Publicar el agente de datos o actualizar su descripción de publicación.

Cualquier cambio, ya sea funcional o descriptivo, hace que el agente de datos no se sincronice con el repositorio git vinculado. Los elementos del área de trabajo con cambios aparecerán en la pestaña Cambios del panel Control de código fuente. Puede revisar estos cambios, compararlos con la versión confirmada y confirmarlos de nuevo en el repositorio de Git para sincronizarlos.

5. Cuando las actualizaciones se realizan directamente en el repositorio git vinculado (Azure DevOps o GitHub), pueden incluir acciones como modificar instrucciones de IA, cambiar consultas de ejemplo o editar descripciones de publicación. Después, puede confirmar e insertar esos cambios en el repositorio. Una vez que las actualizaciones se insertan y están disponibles en el repositorio, el área de trabajo de Fabric las detecta y muestra una notificación actualizaciones disponibles en el panel Control de código fuente. Los elementos actualizados, como el agente de datos, aparecen en la pestaña Actualizaciones, donde puede revisarlos y aceptarlos. La aceptación de estas actualizaciones aplica los cambios del repositorio a los elementos del área de trabajo, lo que garantiza que el área de trabajo refleje la versión confirmada más reciente en Git.

Estructura de carpetas y archivos en el repositorio de Git

En lo siguiente, revisará la estructura de cómo se almacena la configuración de un agente de datos en un repositorio de Git. Comprender esta estructura es importante para administrar los cambios y seguir los procedimientos recomendados.

Estructura raíz

En la raíz, el contenido del agente de datos se almacena en la carpeta files . Dentro de los archivos, encontrará una carpeta config , que contiene data_agent.json, publish_info.json, draft folder y published folder.

Dentro de la carpeta config , el publish_info.json contiene la descripción de publicación del agente de datos. Este archivo se puede actualizar para cambiar la descripción que aparece cuando se publica el agente de datos.

La carpeta draft contiene los archivos de configuración correspondientes a la versión de borrador del agente de datos y la carpeta publicada contiene los archivos de configuración de la versión publicada del agente de datos. La carpeta borrador contiene:

• Carpetas de origen de datos donde hay una carpeta para cada origen de datos usado por el agente de datos.
  • Orígenes de datos de lakehouse o almacén de datos: los nombres de carpeta comienzan por lakehouse-tables- o warehouse-tables-, seguidos del nombre del lakehouse o almacén de datos.
  • Orígenes de datos del modelo semántico: los nombres de carpeta comienzan por semantic-model-, seguido del nombre del modelo semántico.
  • Orígenes de datos de base de datos KQL: los nombres de carpeta comienzan por kusto-, seguido del nombre de la base de datos KQL.
  • Orígenes de datos de ontología: los nombres de carpeta comienzan por ontology-, seguido del nombre de la ontología.

• stage_config.json que contiene aiInstructions, que hace referencia a las instrucciones del agente.

Cada carpeta del origen de datos contiene datasource.json y fewshots.json. Sin embargo, si el origen de datos es un modelo semántico, no admite consultas de ejemplo, por lo que su carpeta solo contiene datasource.json.

El datasource.json define la configuración de ese origen de datos, entre las que se incluyen:

• dataSourceInstructions, que representa las instrucciones proporcionadas para ese origen de datos.

• displayName, que muestra el nombre del origen de datos.

• elements, que hace referencia al mapa de esquema e incluye una lista completa de tablas y columnas del origen de datos.

  • Cada tabla tiene una is_selected propiedad . Si truees , la tabla se incluye y, si false, significa que la tabla no está seleccionada y no la usará el agente de datos.
  • Las entradas de columna también muestran is_selected, pero actualmente no se admite la selección de nivel de columna. Si se selecciona una tabla, todas sus columnas se incluyen independientemente del valor de columna is_selected . Si no se selecciona una tabla (is_selected: false en el nivel de tabla), no se tiene en cuenta ninguna de las columnas a pesar de que is_selected se establece true en en el nivel de columna.

• Convenciones de tipo:

  • Si el tipo es un origen de datos, es simplemente el tipo de origen de datos (por ejemplo: "type": "lakehouse_tables").
  • Si el tipo es una tabla, finaliza con .table (por ejemplo: "type": "lakehouse_tables.table").
  • Si el tipo es una columna, finaliza con .column (por ejemplo: "type": "lakehouse_tables.column").

El fewshots.json almacena consultas de ejemplo para el origen de datos. Cada entrada incluye:

• id como identificador único de la consulta de ejemplo.
• question, que hace referencia a la pregunta del lenguaje natural.
• query muestra el texto de la consulta, que puede ser SQL o KQL en función del tipo de origen de datos.

La carpeta publicada refleja la estructura de la carpeta borrador, pero representa la versión publicada del agente de datos. Se recomienda no modificar los archivos de la carpeta publicada directamente. Los cambios deben realizarse en la carpeta borrador. Una vez publicado el agente de datos, esos cambios se reflejan en la carpeta publicada. Esto garantiza que la versión publicada siempre se genere a partir de un estado de borrador controlado.

Flujos de implementación para agentes de datos

Las canalizaciones de implementación proporcionan una manera controlada de mover agentes de datos entre áreas de trabajo asignadas a distintas fases del ciclo de vida. Por ejemplo:

1. Desarrolle un nuevo agente de datos o actualice uno existente en el área de trabajo de desarrollo.
2. Promover los cambios en el área de trabajo de prueba para la validación.
3. Promueva los cambios probados en el área de trabajo de producción donde está disponible para los usuarios finales.

Antes del despliegue, debe asignar un espacio de trabajo a cada etapa del pipeline de despliegue: desarrollo, prueba y producción. Si no asigna un área de trabajo a la fase de prueba o producción, las áreas de trabajo se crean automáticamente. Las áreas de trabajo creadas automáticamente se nombran a partir del área de trabajo de desarrollo, con [prueba] o [prod] agregados.

Para implementar cambios:

• En la canalización, vaya a la fase desde la que desea realizar la implementación (por ejemplo, desarrollo).
• Seleccione los elementos del área de trabajo que desea implementar.
• Seleccione Implementar para promocionarlos a la siguiente fase.

Puede revisar un plan de implementación antes de aplicar los cambios, asegurándose de que solo se promueven las actualizaciones previstas. Para más información, consulte Introducción a las canalizaciones de implementación.

Nota:

Las entidades de servicio solo se admiten en el agente de datos de Fabric como parte de los escenarios de ALM. Esta compatibilidad se limita a habilitar las operaciones de ALM (como las canalizaciones de integración e implementación de Git) y no se extiende a otras características del agente de datos de Fabric. Si necesita interactuar con un agente de datos fuera de los flujos de trabajo de ALM, no se admite el principal de servicio.

Publicación de un agente de datos de Fabric para las canalizaciones de implementación

La publicación de un agente de datos de Fabric hace que esté disponible para su uso en todos los distintos canales de consumo, incluidos Copilot para Power BI, Microsoft Copilot Studio y Azure AI Foundry Services. Para evaluar y consumir el agente de datos en estos canales, es necesario publicar el agente de datos; los agentes de datos no publicados no son accesibles para su consumo, incluso si están en un entorno de trabajo de producción. Para seguir las mejores prácticas de acuerdo con el flujo de despliegue, tenga en cuenta que:

• La publicación desde un área de trabajo de desarrollo debe limitarse a los usuarios autorizados solo que trabajan en el desarrollo del agente de datos y desean evaluar su rendimiento en diferentes canales de consumo. El acceso a este espacio de trabajo debe estar restringido para que los agentes de datos no terminados o experimentales no se expongan a un público más amplio.
• Los usuarios finales deben acceder solo a los agentes de datos publicados desde el área de trabajo de producción, lo que garantiza que interactúan con versiones estables y aprobadas del agente de datos.

Este enfoque admite tanto el requisito funcional de habilitar el consumo como la evaluación del rendimiento, y garantiza un control de acceso adecuado al mantener separados los entornos de desarrollo y producción.

procedimientos recomendados

• Utilice una rama dedicada para el trabajo de desarrollo en agentes de datos y fusione con la rama principal después de la revisión del código.
• Mantenga los recursos relacionados (orígenes de datos, agentes de datos, cuadernos, canalizaciones) en la misma área de trabajo para facilitar la promoción.
• Pruebe los cambios del agente de datos en el área de trabajo de prueba antes de implementar en producción.
• Use mensajes de confirmación descriptivos para facilitar la comprensión del historial.
• No realice cambios directamente en la carpeta publicada en el repositorio de Git.

Limitaciones y consideraciones

• Solo las áreas de trabajo conectadas a un repositorio de Git pueden usar características de ALM basadas en Git.
• Los principales de servicio se admiten solo en el agente de datos de Fabric como parte de los escenarios de ALM. Si necesita interactuar con un agente de datos fuera de los flujos de trabajo de ALM, no se admite el principal de servicio.
• Los flujos de trabajo de implementación requieren que las áreas de trabajo de origen y de destino estén en el mismo tenant.
• Un gran número de confirmaciones frecuentes puede afectar al tamaño y al rendimiento del repositorio.

Contenido relacionado

• Introducción a la integración de Git
• Conceptos básicos de la integración de Git
• ¿Qué es la administración del ciclo de vida en Microsoft Fabric?