Paneles de control de versiones con Git

En esta página se explica cómo usar carpetas de Git de Databricks para el control de versiones y el desarrollo de paneles colaborativos. También se describe cómo implementar procesos de CI/CD para desarrollar e implementar paneles en diferentes áreas de trabajo.

Importante

Esta característica está en versión preliminar pública.

Visión general

Las carpetas de Git de Databricks realizan un seguimiento de los cambios y el historial del panel, la colaboración del equipo de soporte técnico y permiten implementar paneles en producción y recuperar versiones anteriores.

Habilitación del control de código fuente del panel

Los administradores del área de trabajo pueden controlar el acceso al área de trabajo a la versión preliminar pública desde la página Versiones preliminares. De forma predeterminada, los paneles de soporte técnico en la vista previa de carpetas de Git están activados.

Funcionamiento de la integración de Git con paneles

Las carpetas de Git de Databricks realizan un seguimiento y administran los cambios en los paneles de borrador . El borrador del panel refleja todos los cambios en un panel con seguimiento. Git no realiza un seguimiento de las configuraciones de publicación y programación, como la selección de almacenamiento y la creación de la programación. Para administrar estas configuraciones, use la interfaz de usuario o automatice los cambios con los conjuntos de recursos de Databricks o la API rest de AI/BI.

• Para usar agrupaciones para la administración de paneles, consulte panel.
• Para publicar y programar paneles con la API REST, consulte la referencia de la API de Lakeview .

Nota:

La API de Lakeview usa el nombre anterior para los paneles de AI/BI.

Las carpetas de Git de Databricks administran operaciones comunes de Git para paneles y otros objetos de área de trabajo. Para más información, consulte Carpetas de Git de Azure Databricks.

Aplicación del control de código fuente a los paneles

Para realizar un seguimiento de los paneles con Git, colóquelos en una carpeta de Git de Databricks. Use una de las siguientes opciones:

• Nuevos paneles: Cree el panel dentro de una carpeta de Git de Databricks existente para aplicar el control de código fuente desde el principio.
• Paneles existentes: Mueva un panel existente a una carpeta de Git de Databricks para realizar el seguimiento con Git.

Administración de permisos para paneles controlados por código fuente

Los permisos de nivel de carpeta se aplican a todos los objetos de esa carpeta, incluidos los paneles. Los paneles de una carpeta git heredan los permisos de la carpeta primaria, además de los permisos específicos del panel. La mayoría de las operaciones de Git requieren el permiso CAN MANAGE. Para más información, consulte ACL de carpetas y ACL de carpetas de Git.

Flujo de trabajo de desarrollo recomendado

Clone el repositorio en su propia carpeta git de Databricks, use ramas de características y envíe solicitudes de incorporación de cambios. En la tabla siguiente se describe cómo usar carpetas de Git para administrar paneles durante diferentes fases de desarrollo e implementación.

Importante

Cambiar las ramas de Git es una operación destructiva para los paneles. Azure Databricks elimina los paneles que no existen en la rama de destino. Si cambia de nuevo, los paneles reaparecen con nuevas direcciones URL e identificadores, lo que puede interrumpir los vínculos publicados, los marcadores y las integraciones de API. Compruebe la rama de destino antes de cambiar y actualizar todas las referencias después.

Fase del proyecto	Flujo de trabajo	Resultado previsto	Limitaciones conocidas
Confirmación inicial	Mueva el panel a una carpeta de Git en el área de trabajo. Confirme e inserte en el repositorio de Git remoto.	Git realiza un seguimiento del panel en un repositorio remoto.
Desarrollo	Los desarrolladores crean carpetas de Git en ramas de desarrollo independientes, normalmente en sus carpetas principales. Confirme los cambios en la rama de desarrollo. Combine ramas de desarrollo a Main mediante solicitudes de incorporación de cambios.	Los desarrolladores trabajan de forma independiente. Git realiza un seguimiento de las versiones del panel.	Los archivos de panel usan el formato JSON. Las consultas SQL aparecen como una sola línea, lo que puede dificultar la revisión en las solicitudes de incorporación de cambios.
Despliegue	Cree una carpeta git en la rama de implementación en una carpeta de nivel superior que no sea de usuario. Consulte CI/CD en carpetas Git de Databricks. Extraiga los cambios en la carpeta de implementación. Publicar paneles desde esta carpeta. Quite el acceso edit+ y restrinja las actualizaciones a Git. Compartir paneles con consumidores.	Los consumidores acceden a una versión coherente y publicada del panel. Puede compartir paneles en la misma carpeta con diferentes audiencias.	Databricks no proporciona compatibilidad integrada para sincronizar una rama remota con una carpeta de Git en el área de trabajo o implementar conjuntos de recursos de Databricks con un recurso de panel desde remoto. Configure la automatización de CI/CD para automatizar: Extraer actualizaciones del repositorio remoto. Publicar paneles después de la sincronización. Implementación de conjuntos de recursos de Databricks después de una actualización.

Para obtener más procedimientos recomendados sobre la colaboración en carpetas de Git de Databricks, consulte Colaboración con carpetas de Git.

Limitaciones

El control de código fuente con paneles de IA/BI tiene las siguientes limitaciones:

• Se puede confirmar un máximo de 100 paneles en una sola carpeta de Git. Este límite puede cambiar durante la versión preliminar pública.
• Los trabajos basados en Git, como los trabajos que hacen referencia a direcciones URL de Git en lugar de identificadores de recursos o rutas de acceso del área de trabajo, no funcionan con paneles.
• La serialización del panel genera cadenas largas, lo que dificulta la lectura y revisión de las diferencias durante las solicitudes de incorporación de cambios.
• El formato de archivo del panel cambia periódicamente para incluir nuevos campos y otras mejoras. Durante la fase de vista previa pública, estos cambios pueden manifestarse como diferencias en Git que usted no inició.