Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se explica a los desarrolladores cómo integrar el control de versiones de Git con la herramienta de administración del ciclo de vida de aplicaciones (ALM) de Microsoft Fabric.
Nota:
Algunos de los elementos para la integración de Git están en versión preliminar. Para obtener más información, consulte la lista de elementos admitidos.
La integración de Git en Microsoft Fabric permite a los desarrolladores integrar sus procesos de desarrollo, herramientas y procedimientos recomendados directamente en la plataforma fabric. Permite a los desarrolladores que desarrollan en Fabric:
- Hacer copias de seguridad y versiones de su trabajo
- Revertir a las fases anteriores según sea necesario
- Colaborar con otros usuarios o trabajar solos con ramas de Git
- Utilizar las funcionalidades de las herramientas de control de código fuente conocidas para administrar elementos de Fabric
La integración con el control de código fuente está a nivel de espacio de trabajo. Los desarrolladores pueden crear versiones de los elementos que desarrollan dentro de un área de trabajo en un único proceso, con visibilidad completa a todos sus elementos. La estructura del área de trabajo, incluidas las subcarpetas, se conserva en el repositorio de Git.
Consulte la lista de elementos admitidos.
Lea los conceptos básicos de Git y control de versiones .
Obtenga más información sobre el proceso de integración de Git.
Obtenga información sobre la mejor manera de administrar las ramas de Git.
Seguridad de red para la integración de Git
La seguridad a nivel de espacio de trabajo en Microsoft Fabric ofrece un control detallado sobre el acceso a datos y la conectividad de red, permitiendo que los administradores configuren protecciones entrantes y salientes para espacios de trabajo individuales. Estos controles garantizan que los datos confidenciales permanecen dentro de los límites de red de confianza y se integran con herramientas de CI/CD, como la integración de Git. Para obtener más información, consulte Seguridad de red para la integración continua o la implementación continua.
Información sobre privacidad
Antes de habilitar la integración de Git, asegúrese de revisar las siguientes declaraciones de privacidad:
- Declaración de privacidad de Microsoft
- Introducción a la protección de datos de DevOps Services Azure
- GitHub Contrato de protección de datos
Proveedores de Git compatibles
Se admiten los siguientes proveedores de Git:
- Azure DevOps (solo basado en la nube)
- GitHub (solo basado en la nube)
- GitHub Enterprise (solo basado en la nube)
Elementos admitidos
Actualmente, los siguientes elementos admiten la integración de Git:
Elementos de ingeniería de datos:
- Medio ambiente
- GraphQL
- Lakehouse
- Blocs de notas
- Definiciones de trabajos de Spark
- Funciones de datos de usuario
Elementos de ciencia de datos:
- Experimentos de aprendizaje automático(preview)
- modelos de aprendizaje automático(preview)
- Agentes de datos(versión preliminar)
Elementos de Data Factory:
Elementos de Inteligencia en tiempo real:
- Activator(preview)
- Eventhouse
- EventStream
- base de datos KQL
- KQL Queryset
- Panel en tiempo real
- Conjunto de esquemas de eventos(versión preliminar)
- Maps(preview)
- Detección de anomalías(versión preliminar)
Elementos del almacén de datos
- Almacén(versión preliminar)
- Catálogo de Azure Databricks Espejado
Elementos de Power BI:
- Conjunto de métricas (versión preliminar)
- aplicación Org(vista previa)
- Informe paginado(vista previa)
- Report (excepto los informes conectados a modelos semánticos hospedados en Azure Analysis Services, SQL Server Analysis Services o informes exportados por Power BI Desktop que dependen de modelos semánticos hospedados en MyWorkspace) (preview)
- Modelo semántico (excepto conjuntos de datos de inserción, conexiones dinámicas a Analysis Services, modelo v1) (versión preliminar)
Elementos de base de datos:
- Base de datos SQL
- Cosmos base de datos (vista previa)
Gráfico:
Soluciones del sector:
- Healthcare(preview)
- HealthCare Cohort (versión preliminar)
Si el área de trabajo o el directorio de Git tiene elementos no admitidos, podrá seguir conectándose, pero se ignorarán los elementos no admitidos. No se guardan ni sincronizan, pero tampoco se eliminan. Aparecen en el control panel de origen, pero no se pueden confirmar ni actualizar.
Consideraciones y limitaciones
Limitaciones generales de integración de Git
- El método de autenticación de Fabric debe ser al menos tan seguro como el método de autenticación para Git. Por ejemplo, si Git requiere autenticación multifactor, Fabric también necesita autenticación multifactor.
- Los conjuntos de datos de Power BI conectados a Analysis Services no se admiten en este momento.
- Si usa una identidad de área de trabajo en un artefacto y la confirma en Git, solo se puede actualizar (volver a un área de trabajo de tejido) en un área de trabajo conectada a la misma identidad. Tenga cuidado, ya que esto también afecta a características como la ramificación.
- No se admiten submódulos.
- No se admiten las nubes soberanas.
- Si el área de trabajo contiene cientos de elementos, considere la posibilidad de dividirlo en conjuntos más pequeños de artifacts. Cada conjunto debe colocarse en un área de trabajo independiente y vincularse a otra rama de Git o conectarse a una sola rama organizada en carpetas diferentes.
- Azure DevOps no se admite si la Habilitación de la validación de la directiva de acceso condicional de IP está habilitada.
- Si el área de trabajo y el repositorio de Git están en dos regiones geográficas diferentes, el administrador del inquilino debe habilitar las exportaciones entre regiones geográficas.
- Si su organización configuró acceso condicional, asegúrese de que el servicio de Power BI tenga el mismo conjunto de condiciones para que la autenticación funcione según lo previsto.
- Se aplica el siguiente límite de tamaño de confirmación:
- 25 MB mediante el conector de Azure DevOps con el Principal del Servicio.
- 125 MB utilizando la cuenta predeterminada de inicio de sesión único (SSO) de Microsoft Entra ID y el conector de Azure DevOps con Principal de Usuario.
limitaciones de GitHub Enterprise
No se admiten algunas versiones y configuraciones de GitHub Enterprise. Por ejemplo:
- No se admite GitHub Enterprise Server con un dominio personalizado, incluso si la instancia es públicamente accesible
- GitHub Enterprise Server hospedado en una red privada
- Lista de direcciones IP permitidas
Migración de Azure DevOps a GitHub Enterprise
Si el equipo usa Fabric Git Integration y está evaluando una migración de Azure DevOps a GitHub Enterprise, se recomienda ejecutar pruebas de validación para asegurarse de que la funcionalidad de integración de Git sigue sin verse afectada. La integración de Git de Fabric se basa en las API del proveedor de Git subyacentes, que difieren en las funcionalidades y limitaciones entre Azure DevOps y GitHub Enterprise, como se ha descrito anteriormente.
Limitaciones del área de trabajo
- Solo el administrador del área de trabajo puede administrar las conexiones a la Git Repo como conectarse, desconectar o agregar una rama.
Una vez conectado, cualquier persona con permiso puede trabajar en el área de trabajo. - Las áreas de trabajo con aplicaciones de plantilla instaladas no se pueden conectar a Git.
- MyWorkspace no se puede conectar a un proveedor de Git.
- Las áreas de trabajo pueden contener un máximo de 1000 elementos. Si la rama de Git contiene más de 1000 elementos, se producirá un error al sincronizar el contenido con el área de trabajo. Para evitar esta limitación, considere dividir los artefactos en conjuntos más pequeños. Cada conjunto debe colocarse en un área de trabajo independiente y vincularse a otra rama de Git o organizarse en carpetas diferentes dentro de una sola rama. Para obtener más información, consulte los límites de ítems del espacio de trabajo.
Limitaciones de rama y carpeta
- La longitud máxima del nombre de rama es de 244 caracteres.
- La longitud máxima de la ruta de acceso completa para los nombres de archivo es de 250 caracteres. Se produce un error en los nombres más largos.
- El tamaño máximo de archivo es de 25 MB.
- La estructura de carpetas se mantiene hasta 10 niveles de profundidad.
- No se recomienda descargar un informe o un conjunto de datos como .pbix desde el servicio después de implementarlos con la integración de Git, ya que los resultados no son confiables. Se recomienda usar Power BI Desktop para descargar informes o conjuntos de datos como .pbix.
- Si el nombre para mostrar del elemento tiene cualquiera de estas características, se cambia el nombre de la carpeta Git al identificador lógico (Guid) y el tipo:
- Tiene más de 256 caracteres
- Termina con . o un espacio
- Contiene caracteres prohibidos, según se describe en las limitaciones del nombre de directorio
- Al conectar un área de trabajo que tiene carpetas a Git, debe confirmar los cambios en el repositorio de Git si esa estructura de carpetas es diferente.
Limitaciones del nombre del directorio
El nombre del directorio que se conecta al repositorio de Git tiene las siguientes restricciones de nomenclatura:
- El nombre del directorio no puede comenzar ni terminar con un espacio o una pestaña.
- El nombre del directorio no puede contener ninguno de los siguientes caracteres: ":?
La carpeta item (la carpeta que contiene los archivos de elementos) no puede contener ninguno de los siguientes caracteres: ":?. Si cambia el nombre de la carpeta a algo que incluye uno de estos caracteres, Git no se puede conectar ni sincronizar con el área de trabajo y se produce un error.
Limitaciones en la expansión
- La ramificación requiere permisos que se muestran en la tabla de permisos.
- Debe haber una capacidad disponible para esta acción.
- Todas las limitaciones de nomenclatura de área de trabajo y limitaciones de nomenclatura de rama se aplican al ramificar hacia una nueva área de trabajo.
- Solo los elementos compatibles con Git están disponibles en el nuevo área de trabajo.
- La lista de ramas relacionadas solo muestra ramas y áreas de trabajo que tiene permiso para ver.
- La integración de Git debe estar habilitada.
- Al bifurcar, se crea una nueva rama y no se copia la configuración de la rama original. Ajuste cualquier configuración o definiciones para asegurarse de que el nuevo cumple las directivas de la organización.
- Al ramificarse en un área de trabajo existente:
- El área de trabajo de destino debe admitir una conexión de Git.
- El usuario debe ser un administrador del área de trabajo de destino.
- El área de trabajo de destino debe tener capacidad.
- El área de trabajo no puede tener aplicaciones de plantilla.
- Tenga en cuenta que, cuando se expande a un área de trabajo, los elementos que no se hayan guardado en Git se pueden perder. Se recomienda confirmar los elementos que quiera conservar antes de crear una nueva rama.
Limitaciones de sincronización y confirmación
- Solo se puede sincronizar en una dirección a la vez. No se puede confirmar y actualizar al mismo tiempo.
- Las etiquetas de confidencialidad no se admiten y es posible que se deshabilite la exportación de elementos con etiquetas de confidencialidad. Para confirmar los elementos que tienen etiquetas de confidencialidad sin la etiqueta de confidencialidad, pida ayuda al administrador .
- Funciona con elementos limitados. Si hay elementos no compatibles en la carpeta, se omiten.
- No se permiten duplicaciones de nombres. Incluso si Power BI permite la duplicación de nombres, se produce un error en la acción de actualización, confirmación o deshacer.
- B2B no está soportado.
- La resolución de conflictos se realiza parcialmente en Git.
- Durante el proceso Commit to Git, el servicio Fabric elimina los archivos dentro de la carpeta de elemento que no forman parte de la definición de elemento. Los archivos no relacionados que no están en una carpeta de elementos no se eliminan.
- Después de confirmar los cambios, es posible que observe algunos cambios inesperados en el elemento que usted no hizo. Estos cambios son semánticamente insignificantes y pueden ocurrir por varias razones. Por ejemplo:
- Cambiar manualmente el archivo de definición de elemento. Estos cambios son válidos, pero pueden ser diferentes de si se realizan a través de los editores. Por ejemplo, si cambia el nombre de una columna de modelo semántico en Git e importa este cambio en el área de trabajo, la próxima vez que confirme los cambios en el modelo semántico, el archivo bim se registrará como modificado y la columna modificada insertada en la parte posterior de la matriz. Esto se debe a que el motor de AS que genera los archivos bim inserta columnas cuyo nombre ha cambiado al final de la matriz. Este cambio no afecta a la forma en que funciona el elemento.
- Confirmar un archivo que usa saltos de línea CRLF. El servicio usa saltos de línea LF (avance de línea). Si tenías archivos en el repositorio de Git con saltos de línea CRLF, cuando confirmas desde el servicio, estos archivos se cambian a LF. Por ejemplo, si abre un informe en el escritorio, guarde el archivo project (.pbip) y cárguelo en Git mediante CRLF.
- La actualización de un modelo semántico mediante la API de actualización mejorada provoca una diferencia de Git después de cada actualización.
Contenido relacionado
- Comienza con la integración de Git
- Descripción del proceso de integración de Git