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 Azure DevOps 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.
¡Importante! en este artículo se obvia el proceso opcional de crear áreas de trabajo y una rama por cada nueva funcionalidad
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 Azure DevOps. Esta integración se utilizará únicamente como control de versiones y mecanismo de trazabilidad de los cambios. Azure DevOpsno 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 Azure DevOps, 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 Azure DevOps 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 Azure DevOps y configurar las canalizaciones de Fabric para mover el contenido entre entornos de forma controlada y predecible.
Preparación del repositorio en Azure DevOps
En este punto vamos a preparar todo lo necesario en Azure Devops 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 proyecto en Azure DevOps y, dentro de él, un repositorio Git estándar, sin aplicar plantillas ni configuraciones avanzadas. No es necesario configurar pipelines, políticas de rama ni reglas de protección, ya que en este escenario Azure DevOps se utiliza únicamente como sistema de control de versiones.
El repositorio debe tener al menos una rama creada y un commit inicial. Los repositorios completamente vacíos no pueden utilizarse desde Microsoft Fabric.
A diferencia de Azure DevOps, no es necesario generar ningún token de acceso personal. Azure DevOps utiliza autenticación OAuth basada en la identidad del usuario que establece la conexión.
Es importante asegurarse de que el usuario tenga acceso Basic o superior. Los usuarios con acceso Stakeholder no pueden trabajar con Azure Repos, aunque tengan permisos asignados.
Configurar Azure DevOps
- Inicie sesión en Azure DevOps
- Haz clic en el botón Crear una nueva organización.
- Acepta los términos del servicio.
- Escribe un nombre para la organización y en que región se alojarán tus datos (debería coincidir con la región de Power BI o sino habilitar las exportaciones entre áreas geográficas)
- Da nombre al nuevo proyecto y la visibilidad que tendrá.
- Ahora debemos crear una rama en el repositorio para comenzar a guardar los ficheros de Fabric o Power BI. Haz clic en Repos > Branches. Después haz clic en Initilize para crearla.
Es importante destacar aquí que Fabric no se autentica contra Azure Devops 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.
En este punto, Azure DevOps 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 Azure Devops
Una vez creado el repositorio y generado el token de acceso personal en Azure DevOps , 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.
Configurar área de trabajo
- Comprueba que tu área de trabajo es compatible.
- Haz clic en los tres puntos.
- Haz clic en Configuración del área de trabajo.
- Haz clic en Integración con Git, selecciona Azure DevOps y haz clic en Conectar.
- Selecciona la organización, proyecto, repositorio, rama y una carpeta (esta última es opcional, pero recomendada)
- Haz clic en conectar y sincronizar.
Una vez completados estos pasos, se establece la conexión y el área de trabajo queda vinculada a Azure DevOps. 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 Azure DevOps
Una vez completada la vinculación del área de desarrollo con Azure DevOps, 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 Azure DevOps 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 Azure DevOps, 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 Azure DevOps. 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 Azure DevOps, 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 Azure DevOps, 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 Azure DevOps 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.
