Compartir a través de

¿Qué es la integración de Git de Microsoft Fabric?

  • Artículo

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 las 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 tamaños 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 de 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á en un nivel de área 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. Actualmente, en la versión preliminar, solo son compatibles unos pocos elementos, pero la lista de elementos compatibles está creciendo.

Información sobre privacidad

Antes de habilitar la integración de Git, asegúrese de revisar las siguientes declaraciones de privacidad:

Proveedores de Git admitidos

Se admiten los siguientes proveedores de Git:

Elementos admitidos

Actualmente son compatibles los siguientes elementos:

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 panel Control de código fuente, pero no puede confirmarlos ni actualizarlos.

Consideraciones y limitaciones

Limitaciones generales de integración de Git

  • El método de autenticación en 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.
  • Las áreas de trabajo con aplicaciones de plantilla instaladas no se pueden conectar a Git.
  • No se admiten las nubes soberanas.
  • La cuenta de Azure DevOps debe registrarse en el mismo usuario que usa el área de trabajo de Fabric.
  • Si el área de trabajo y el repositorio de Git se encuentran en dos regiones geográficas diferentes, el administrador de inquilinos deberá habilitar las exportaciones entre áreas geográficas.
  • El tamaño de una confirmación está limitado a 125 MB.

Limitaciones de GitHub Enterprise

No se admiten algunas configuraciones de GitHub Enterprise. Por ejemplo:

Limitaciones del área de trabajo

  • Solo el administrador del área de trabajo puede administrar las conexiones al repo de Git, como conectar, desconectar o agregar una rama.
    Una vez conectado, cualquier persona con permiso puede trabajar en el área de trabajo.
  • La estructura de carpetas del área de trabajo no se refleja en el repositorio de Git. Los elementos del área de trabajo de las carpetas se exportan al directorio raíz.

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.
  • No puede descargar un informe o un conjunto de datos como .pbix desde el servicio después de implementarlos con Git Integration.
  • Al nombrar una carpeta de Git, el identificador lógico (GUID) se añade como prefijo antes del tipo en el nombre del elemento.
    • Tiene más de 256 caracteres
    • Termina con . o un espacio
    • Contiene cualquiera de los caracteres siguientes: " / : < > \ * ? |

Limitaciones de ramificació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 rama y área de trabajo y se aplican al ramificar hacia una nueva área de trabajo.
  • Al ramificar, se crea una nueva área de trabajo y no se copia la configuración del área de trabajo original. Ajuste la configuración o las definiciones para garantizar que la nueva área de trabajo cumple las directivas de la organización.
  • Solo los elementos compatibles con Git están disponibles en la nueva á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.

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 es compatible.
  • La resolución de conflictos se realiza parcialmente en Git.
  • Durante el proceso Confirmar en Git, el servicio Fabric elimina los archivos dentro de la carpeta de elementos 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 la columna de un 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 será insertada en la parte posterior de la columns 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ía archivos de elementos en el repositorio de Git con saltos de línea CRLF, al confirmar desde el servicio, estos archivos se cambian a LF. Por ejemplo, si abre un informe en el escritorio, guarde el proyecto .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