Introducción

En el artículo anterior vimos distintas estrategias para gestionar despliegues entre entornos en Microsoft Fabric y el papel que juegan Git y las canalizaciones de la plataforma. En este post vamos a bajar uno de esos escenarios a tierra con un ejemplo práctico completo, sin atajos y sin suposiciones.

En concreto, vamos a implementar el caso más sencillo y habitual: usar GitHub como control de versiones, mientras que el despliegue entre entornos se gestiona mediante las canalizaciones nativas de Microsoft Fabric. Este enfoque no convierte a Git en la fuente de verdad del despliegue, pero sí permite versionar el trabajo, colaborar de forma ordenada y mantener trazabilidad de los cambios.

El objetivo no es mostrar un entorno idealizado, sino reproducir un escenario realista, paso a paso, tal y como se suele implantar en la mayoría de equipos que empiezan a trabajar con Microsoft Fabric.

Escenario de partida

Antes de entrar en la configuración paso a paso, es importante dejar claro el escenario que vamos a implementar y, sobre todo, qué decisiones de diseño hemos tomado desde el principio. Este ejemplo no pretende cubrir todos los casos posibles, sino reflejar un escenario sencillo y muy habitual en proyectos reales con Microsoft Fabric.

Partimos de tres áreas de trabajo claramente diferenciadas:

• Área de desarrollo, donde se realizan los cambios y se trabaja de forma habitual.
• Área de pruebas, destinada a validar los cambios antes de su liberación.
• Área de producción, donde se publica el contenido final para los usuarios.

El área de desarrollo estará conectada a un repositorio de GitHub. Esta integración se utilizará únicamente como control de versiones y mecanismo de trazabilidad de los cambios. GitHub no se empleará como origen del despliegue ni como sistema de aprobación técnica.

El paso de contenido entre entornos se realizará exclusivamente mediante las canalizaciones nativas de Microsoft Fabric. Esto significa que el despliegue dependerá del estado del área de desarrollo en el momento de ejecutar la canalización, no del estado del repositorio.

En este ejemplo se utilizará una única rama en GitHub, la rama main. No se trabajará con ramas de desarrollo, pull requests ni flujos avanzados de Git, ya que no son necesarios para este modelo y solo añadirían complejidad sin aportar valor en este contexto.

Tampoco se utilizarán canalizaciones externas de CI/CD ni automatizaciones basadas en APIs. Todo el proceso de despliegue se gestionará desde Fabric, manteniendo GitHub como un repositorio de apoyo al desarrollo y no como la fuente de verdad del despliegue.

Con este escenario definido, en los siguientes apartados veremos cómo preparar el repositorio, conectar el área de desarrollo a GitHub y configurar las canalizaciones de Fabric para mover el contenido entre entornos de forma controlada y predecible.

Preparación del repositorio en GitHub

En este punto vamos a preparar todo lo necesario en GitHub antes de tocar Microsoft Fabric. La idea es dejar el repositorio listo para que el área de desarrollo pueda conectarse sin problemas en el siguiente paso.

Se crea un repositorio nuevo en GitHub, sin aplicar plantillas ni configuraciones avanzadas. No es necesario añadir workflows, reglas de protección de rama ni configuraciones de CI/CD, ya que en este escenario GitHub se va a utilizar únicamente como sistema de control de versiones. Basta con un repositorio estándar y una única rama, main.

Una vez creado el repositorio, el siguiente paso es generar un token de acceso personal. Este token será el que utilice Fabric para autenticarse contra GitHub y sincronizar el contenido del área de desarrollo. En los pantallazos se puede ver el proceso completo de creación del token, incluyendo la selección de permisos mínimos necesarios para trabajar con repositorios.

Paso 1 Acceder a la configuración de GitHub: Desde cualquier repositorio de GitHub, accede al menú de usuario situado en la esquina superior derecha y selecciona la opción de configuración. Este paso nos llevará a la configuración global de la cuenta, donde se gestionan las credenciales y accesos.

Paso 2 Acceder a la sección de configuración de desarrollador: Dentro de la configuración de la cuenta, desplázate hasta el final del menú lateral y accede a la sección de configuración para desarrolladores. Desde aquí se gestionan las aplicaciones y los tokens de acceso personal.

Paso 3 Crear un nuevo token de acceso personal: En la sección de tokens de acceso personal, selecciona la opción de tokens con permisos específicos y genera un nuevo token. Este tipo de token permite limitar el acceso únicamente a los repositorios y permisos necesarios, algo especialmente recomendable cuando se utiliza con herramientas externas como Microsoft Fabric.

Paso 4 Configurar los datos básicos del token: Asigna un nombre descriptivo al token para poder identificarlo fácilmente más adelante. Selecciona el propietario del recurso y define la caducidad del token según la política de seguridad que quieras aplicar. En este ejemplo se utiliza un único repositorio y no se concede acceso global a todos los repositorios de la cuenta.

Paso 5 Definir los permisos del token y generarlo: Selecciona únicamente el repositorio que se va a sincronizar con el área de desarrollo y concede permisos de lectura y escritura sobre el contenido del repositorio. No es necesario añadir permisos adicionales. Una vez definidos los permisos mínimos, genera el token y guárdalo en un lugar seguro, ya que no volverá a mostrarse.

Es importante destacar aquí que Fabric no se autentica contra GitHub utilizando la identidad del usuario final de forma automática, sino mediante un token de acceso personal configurado en la conexión. En función de cómo se haya definido esta conexión, los commits que se generen desde el área de desarrollo aparecerán asociados a la cuenta propietaria de dicho token.

En este ejemplo se utiliza una única conexión para simplificar el escenario, pero en entornos más controlados es habitual que cada usuario configure su propia conexión a Git con su cuenta, de modo que los commits reflejen correctamente la autoría real de los cambios. Este matiz es importante y se tratará con más detalle más adelante.

Con el repositorio creado y el token generado, no es necesario hacer nada más en GitHub en este momento. No se debe subir contenido manualmente ni crear estructuras de carpetas, ya que será Fabric quien genere automáticamente la estructura del repositorio en la primera sincronización.

En este punto, GitHub queda preparado y a la espera de que el área de desarrollo de Fabric se vincule al repositorio. En el siguiente apartado veremos cómo realizar esa conexión desde Fabric y cómo se produce la sincronización inicial.

Vincular el área de desarrollo de Microsoft Fabric con GitHub

Una vez creado el repositorio y generado el token de acceso personal en GitHub, el siguiente paso consiste en vincular el área de trabajo de desarrollo de Microsoft Fabric con dicho repositorio.

Desde el área de trabajo correspondiente al entorno Dev, accede a la configuración del área de trabajo y selecciona la opción de integración con Git.
Esta opción solo está disponible para usuarios con rol de Administrador o Miembro del área de trabajo. Los usuarios con rol de Colaborador o Visor no pueden configurar ni modificar la conexión con Git.

En primer lugar, se selecciona GitHub como proveedor y se hace clic en el botón Agregar cuenta.

En este punto, Fabric no redirige a un flujo de autenticación interactivo, sino que solicita introducir manualmente un token de acceso personal previamente generado en GitHub (el que generamos anteriormente). Este token será el mecanismo que utilice Fabric para leer y escribir en el repositorio.

A continuación, se debe indicar la URL del repositorio que se va a utilizar como origen del control de versiones.

Paso 1 ver repositorios: Vuelve a GitHub y haz clic en el icono de GitHub situado en la esquina superior izquierda para acceder a la página principal. Desde ahí, selecciona el repositorio que se va a utilizar para almacenar los artefactos de Microsoft Fabric.

Paso 2 Copiar la URL del repositorio: Una vez dentro del repositorio, copia la dirección completa que aparece en la barra de direcciones del navegador. Esta será la URL que se utilizará más adelante para vincular el área de trabajo de Microsoft Fabric con GitHub.

Paso 3 Pegar la URL en la configuración de Fabric: Regresa a la configuración del área de trabajo en Microsoft Fabric y pega la URL del repositorio en el campo correspondiente. Si la URL y el token son correctos, Fabric validará automáticamente el acceso al repositorio y permitirá continuar con la configuración.

Haz clic en conectar y selecciona la rama que se va a asociar al área de desarrollo. En este ejemplo se utiliza la rama main, ya que Git actúa únicamente como repositorio de control de versiones y no como mecanismo de despliegue entre entornos. Opcionalmente, puede definirse una carpeta dentro del repositorio para almacenar el contenido del área de trabajo. Si no se especifica ninguna carpeta, Fabric gestionará automáticamente la estructura necesaria en la raíz del repositorio, si se especifica y no existe, pedirá confirmación para crearla.

Una vez completados estos pasos, se establece la conexión y el área de trabajo queda vinculada a GitHub. A partir de este momento, cualquier cambio realizado en el área de desarrollo podrá sincronizarse con el repositorio mediante el control de código fuente de Fabric.

Primera sincronización automática con GitHub

Una vez completada la vinculación del área de desarrollo con GitHub, Fabric realiza automáticamente una primera sincronización del contenido del área de trabajo con el repositorio.

Esta sincronización inicial crea la estructura base en GitHub y genera el primer commit con los artefactos existentes en el área de desarrollo. No es necesario realizar ninguna acción manual adicional para este primer envío, siempre que la configuración del repositorio, la rama y el token sean correctos.

A partir de este momento, el área de trabajo queda oficialmente versionada y Fabric comienza a mostrar el estado de cada elemento respecto a Git. En el panel de control de código fuente se indican claramente los elementos sincronizados y aquellos que contienen cambios pendientes de confirmar.

Cualquier modificación que se realice en el entorno de desarrollo no se envía automáticamente al repositorio. El cambio queda marcado como pendiente y será el usuario quien, de forma explícita, decida cuándo confirmar los cambios y generar un nuevo commit desde el control de código fuente de Fabric.

Estados de sincronización en el área de trabajo

Una vez que el área de desarrollo está vinculada a GitHub, Microsoft Fabric muestra el estado de cada elemento respecto al repositorio. Este estado permite saber rápidamente si un artefacto está sincronizado o si contiene cambios pendientes.

Cuando un elemento aparece como sincronizado, significa que su definición actual coincide con la versión almacenada en GitHub. En cambio, cuando se muestra como no confirmado, indica que se han realizado cambios en el área de trabajo que todavía no se han enviado al repositorio.

Este comportamiento es intencionado: Fabric no realiza commits de forma automática. El usuario mantiene siempre el control sobre cuándo un cambio debe convertirse en una nueva versión en Git, evitando así subir modificaciones incompletas o no deseadas.

Qué se versiona realmente en Git

Cuando se utiliza Git como sistema de control de versiones en Microsoft Fabric, no se versiona el estado completo del entorno ni los datos almacenados, sino la definición de los elementos del área de trabajo.

Esto incluye, por ejemplo, la estructura de los modelos semánticos, las definiciones de informes, los objetos de un lakehouse o las configuraciones de los distintos artefactos. Los datos cargados, el estado de ejecución o los resultados derivados del uso del entorno no forman parte del control de versiones.

Este enfoque permite tratar Git como un repositorio de definiciones reproducibles, facilitando el seguimiento de cambios y la recuperación de versiones anteriores, sin mezclar información operativa o datos sensibles dentro del repositorio.

Qué no hace Git en este escenario

Aunque Git se utiliza como sistema de control de versiones, es importante entender qué responsabilidades no asume dentro de este modelo.

Git no se encarga de desplegar contenido entre entornos, no valida cambios ni ejecuta pruebas automáticamente, y tampoco sustituye a las canalizaciones de despliegue de Microsoft Fabric. Su función se limita a almacenar versiones de las definiciones y a proporcionar trazabilidad sobre los cambios realizados.

Esto significa que un commit en Git no implica que el contenido se haya desplegado en otros entornos, ni que esté aprobado para producción. El despliegue sigue siendo una decisión explícita que se realiza desde Fabric, normalmente mediante canalizaciones de despliegue.

Entender esta separación de responsabilidades es clave para evitar expectativas incorrectas y diseñar un flujo de trabajo coherente.

Configuración de las canalizaciones de despliegue en Fabric

Una vez que el área de desarrollo está correctamente versionada en GitHub, el siguiente paso es configurar las canalizaciones de despliegue de Microsoft Fabric para promover el contenido entre entornos.

En este modelo, las canalizaciones son las responsables de mover el contenido desde el área de desarrollo hacia las áreas de pruebas y producción. Git no interviene en este proceso ni decide qué se despliega; su función se limita al control de versiones del trabajo realizado en el entorno de desarrollo.

La configuración detallada de las canalizaciones de Fabric queda fuera del alcance de este artículo y se tratará en un contenido específico. En este punto es suficiente entender que, sin canalizaciones, los cambios versionados en Git no llegarán a los entornos superiores.

Con esto queda completo el flujo de trabajo de este escenario: desarrollo y versionado en GitHub, y despliegue controlado mediante las herramientas nativas de Microsoft Fabric.

Conclusiones del escenario práctico

En este ejemplo práctico hemos implementado el escenario más sencillo y habitual de integración entre GitHub y Microsoft Fabric: Git como sistema de control de versiones y las canalizaciones nativas de Fabric como mecanismo de despliegue entre entornos.

Este modelo permite trabajar de forma ordenada en el área de desarrollo, mantener un histórico de cambios y facilitar la colaboración entre usuarios, sin introducir la complejidad asociada a flujos avanzados de CI/CD o a Git como fuente de verdad del despliegue. La separación de responsabilidades es clara: Git registra los cambios y Fabric decide cuándo y qué se despliega.

Es importante remarcar que versionar en Git no implica automáticamente desplegar. Los commits reflejan el estado del trabajo en el entorno de desarrollo, pero la promoción a pruebas o producción sigue siendo una acción explícita gestionada desde Fabric. Esta distinción, aunque sencilla, es clave para evitar confusiones habituales cuando se empieza a trabajar con la plataforma.

Este enfoque es especialmente adecuado para equipos pequeños o medianos, para escenarios donde se prioriza la simplicidad operativa y como punto de partida antes de adoptar modelos más avanzados. A partir de aquí, es posible evolucionar hacia estrategias donde Git gobierne el despliegue o se introduzcan canalizaciones externas, siempre que el contexto y la madurez del equipo lo justifiquen.

En próximos artículos se abordarán otros escenarios más avanzados, profundizando tanto en el uso de GitHub como de Azure DevOps para gestionar despliegues en Microsoft Fabric de forma más automatizada.