Introducción
En los últimos meses, la integración de Git en Microsoft Fabric ha generado muchas dudas, especialmente cuando se intenta aplicar modelos clásicos de CI/CD al mundo del dato. Conceptos como ramas, pull requests o despliegues automáticos suelen trasladarse directamente desde el desarrollo de software, pero en Fabric el comportamiento es distinto y, en muchos casos, contraintuitivo. Precisamente por eso es importante entender qué opciones existen realmente y cuáles son sus implicaciones. En este contexto, Estrategias reales de despliegue entre entornos Fabric con Git no trata de mostrar un escenario idealizado, sino de explicar qué funciona hoy, qué no, y cómo diseñar un flujo coherente entre desarrollo, pruebas y producción.
Microsoft Fabric ofrece más de una forma de gestionar el paso entre entornos, desde las canalizaciones nativas de la plataforma hasta modelos más avanzados donde Git se convierte en la fuente única de verdad mediante pipelines externos. Elegir una u otra opción no es solo una decisión técnica, sino también de gobierno, trazabilidad y complejidad operativa. En este artículo vamos a desglosar estos enfoques con ejemplos claros, diagramas y conclusiones prácticas, para que puedas decidir cuál encaja mejor en tu escenario real y no en un diagrama teórico.
Herramientas compatibles con Microsoft Fabric para CI/CD
Actualmente, Microsoft Fabric permite integrar procesos de control de versiones y despliegue mediante dos herramientas principales de CI/CD: GitHub y Azure DevOps. Ambas opciones están soportadas por la plataforma y ofrecen capacidades equivalentes desde el punto de vista funcional, aunque su elección suele depender más del ecosistema y las prácticas ya existentes en la organización que de limitaciones técnicas.
GitHub es una opción natural en escenarios donde ya se utiliza GitHub como repositorio central y se aprovechan GitHub Actions para la automatización de flujos CI/CD. Su integración con Fabric encaja especialmente bien en organizaciones que apuestan por modelos trunk-based, repositorios abiertos o una fuerte adopción de herramientas cloud-native.
Por su parte, Azure DevOps sigue siendo muy habitual en entornos corporativos donde ya existen pipelines consolidados, políticas de rama avanzadas y una gestión centralizada de proyectos. En estos casos, Azure DevOps permite orquestar despliegues hacia Fabric utilizando los mismos mecanismos de compilación y liberación empleados para otras plataformas de datos o aplicaciones.
Es importante destacar que, desde el punto de vista de Fabric, no existe una diferencia funcional entre GitHub y Azure DevOps: en ambos casos, el despliegue se realiza mediante canalizaciones externas que utilizan las APIs de Fabric o librerias externas de Python para crear, actualizar o eliminar elementos en los distintos entornos. Fabric no “lee” directamente desde el repositorio, sino que recibe los cambios a través de estos procesos automatizados.
Una vez aclaradas las herramientas compatibles con Microsoft Fabric, el siguiente paso es entender cómo se pueden combinar Git y los distintos mecanismos de despliegue para gestionar correctamente el paso entre entornos. A continuación se describen tres enfoques habituales, ordenados de menor a mayor complejidad, que cubren la mayoría de escenarios reales.
Opción 1: Git como control de versiones y canalizaciones de Fabric
En muchos escenarios, especialmente cuando se empieza a trabajar con Microsoft Fabric o cuando el foco está en la simplicidad operativa, Git no se utiliza como el motor del despliegue, sino como un mecanismo de control de versiones y colaboración. En este modelo, el repositorio sirve para registrar cambios, revisar evoluciones y mantener un histórico del trabajo realizado, mientras que la promoción del contenido entre entornos se delega completamente a las canalizaciones nativas de la plataforma.
Esta aproximación es la más habitual y la que mejor encaja con la filosofía actual de Fabric. El área de desarrollo se sincroniza con un repositorio Git para versionar los artefactos, pero el paso a las áreas de pruebas y producción no depende del estado de una rama concreta, sino del estado real del workspace en el momento del despliegue. Son las canalizaciones de Fabric las que determinan qué contenido se promueve, cuándo y bajo qué condiciones, manteniendo separadas las responsabilidades de control de cambios y despliegue.
A lo largo de esta sección veremos cómo funciona este modelo en la práctica, qué papel juegan las ramas de Git, qué se considera realmente “aprobado” en este contexto y por qué, en muchos casos, una única rama es suficiente cuando el despliegue se gestiona desde Fabric y no desde el repositorio.
En este enfoque, Git no decide qué llega a producción. Su papel se limita a registrar los cambios que se realizan en el área de desarrollo y a facilitar la colaboración entre personas. El despliegue entre entornos se basa exclusivamente en el estado del área de trabajo y se ejecuta mediante las canalizaciones nativas de Microsoft Fabric.
El flujo real es el siguiente:
- Los desarrollos se realizan directamente en el área de desarrollo.
- Los cambios se sincronizan con el repositorio Git, que actúa como histórico y control de versiones.
- Cuando el contenido está validado funcionalmente, un usuario con los permisos adecuados ejecuta la canalización de Fabric.
- La canalización despliega el contenido desde el área de desarrollo hacia las áreas de pruebas y producción.
Es importante remarcar que, en este modelo, la canalización no tiene en cuenta ramas, pull requests ni estados de Git. Lo que se despliega es siempre una “foto” del área de desarrollo en el momento exacto en que se lanza el despliegue.
Puedes ver el paso a paso de implementar esta solución con GitHub en este otro articulo.
Cuando las canalizaciones de Fabric no son suficientes
El modelo anterior es más que válido para la mayoría de escenarios, pero no cubre todos los casos. En organizaciones con una fuerte cultura DevOps, o cuando se requiere que Git sea la fuente única de verdad, puede resultar insuficiente que el despliegue dependa del estado del área de desarrollo y de una acción manual en Fabric.
En estos contextos, surge la necesidad de invertir el control del proceso: que el repositorio marque qué está aprobado y que los despliegues se ejecuten exclusivamente a partir de ese estado validado. Para ello, Microsoft Fabric ofrece una segunda alternativa más avanzada, basada en canalizaciones externas que utilizan Git como origen y las APIs de Fabric o librerias externas de python como mecanismo de despliegue o librerias externas de python capaces de realizar el paso entre entornos de los artefactos.
Opción 2: Git como fuente de verdad con una única rama y despliegues mediante Actions
En este modelo, Git se convierte en el único punto de aprobación y despliegue, eliminando cualquier dependencia del estado del área de desarrollo. Todo el contenido que llega a los entornos de pruebas y producción procede exclusivamente de la rama main, que actúa a la vez como rama de trabajo y como rama aprobada.
El área de desarrollo se utiliza únicamente como entorno de edición y validación inicial. Los cambios realizados en ella se sincronizan directamente con la rama main del repositorio, sin pasar por ramas intermedias. A partir de ese momento, cualquier despliegue a Test o Producción se ejecuta siempre desde Git, nunca desde el workspace.
Las canalizaciones de compilación y despliegue externas se encargan de recuperar el contenido definido en la rama main y, mediante librerias de python, crear o actualizar los elementos correspondientes en las áreas de pruebas y producción. Fabric no promueve contenido entre entornos ni toma decisiones sobre qué se despliega; se limita a recibir el estado declarado en el repositorio.
En este enfoque, todo lo que está en main se considera aprobado. La disciplina del proceso se apoya en políticas de rama, revisiones obligatorias, validaciones automáticas y controles en el propio pipeline, en lugar de en una separación explícita de ramas. El resultado es un flujo más simple y directo, típico de estrategias trunk-based, pero que exige un mayor rigor en la gestión de cambios.
En este enfoque, Git es el único punto de control del despliegue. El área de desarrollo se utiliza únicamente como entorno de trabajo, pero no decide qué llega a los entornos superiores. Todo lo que se despliega en pruebas y producción proviene exclusivamente de la rama main del repositorio.
El flujo real es el siguiente:
- Los desarrollos se realizan en el Área Dev de Microsoft Fabric.
- Los cambios se sincronizan directamente con la rama main del repositorio Git.
- La rama main representa en todo momento el estado aprobado del contenido.
- Cuando se desea desplegar, se ejecutan las canalizaciones de compilación y despliegue (es posible solicitar aprobación previa al despliegue)
- Estas canalizaciones recuperan el contenido desde la rama main y, utilizando librerias de python o mediante llamadas a las APIs, lo despliegan directamente en el Área Test y posteriormente en el Área Prod.
En este modelo, no existe ninguna promoción interna entre áreas dentro de Fabric. Cada despliegue es una acción explícita del pipeline, que aplica en cada entorno la versión exacta definida en Git.
Qué se despliega realmente
A diferencia del modelo basado en canalizaciones nativas de Fabric, aquí no se despliega una foto del Área Dev, sino una definición declarativa del estado deseado, almacenada en el repositorio.
Esto implica que:
- Solo el contenido presente en la rama main puede llegar a Test y Producción.
- Los cambios no sincronizados o no aprobados en Git no pueden desplegarse, aunque existan en el Área Dev.
- Git se convierte en el punto único de auditoría y trazabilidad del proceso.
En la práctica, el pipeline actúa como un mecanismo de “aplicación del estado”, garantizando que los entornos superiores reflejan exactamente lo que está definido en el repositorio.
Puedes ver el paso a paso de implementar esta solución con GitHub en este otro articulo.
Opción 3: Git como fuente de verdad con dos ramas y despliegues mediante Actions
En este tercer enfoque, el papel de Git cambia por completo. Ya no se utiliza únicamente como un sistema de control de versiones, sino que pasa a convertirse en la fuente única de verdad del despliegue. En este modelo, el contenido que llega a los entornos de pruebas y producción no depende del estado del área de desarrollo, sino exclusivamente de lo que esté aprobado en el repositorio.
Aquí las canalizaciones nativas de Microsoft Fabric no se utilizan para promover contenido entre entornos. En su lugar, se emplean canalizaciones externas de compilación y despliegue que, tras una validación en Git, utilizan librerias de python para crear, actualizar o eliminar los elementos directamente en los workspaces correspondientes.
Este enfoque está pensado para escenarios donde se requiere un control estricto del proceso de despliegue, trazabilidad completa basada en Git y una separación clara entre desarrollo y producción. No es un modelo más sencillo, pero sí uno más predecible cuando Git debe ser el único punto de aprobación.
En las siguientes secciones veremos cómo funciona este flujo paso a paso, qué implicaciones tiene a nivel de ramas y aprobaciones, y por qué este modelo encaja mejor en organizaciones con una cultura DevOps madura.
El flujo se invierte respecto a la opción anterior. Aquí el área de desarrollo no gobierna el despliegue, sino que actúa únicamente como punto de trabajo y sincronización con Git. El control real del proceso vive en el repositorio y en las canalizaciones externas.
El funcionamiento real es el siguiente:
- Los desarrollos se realizan en el área de desarrollo de Microsoft Fabric.
- Los cambios se sincronizan con el repositorio Git, quedando registrados en la rama Dev.
- Se crea una pull request hacia la rama Main desde Dev para el paso entre las diferentes ramas dandolo por aprobado (es posible solicitar confirmacion por un equipo aprobador)
- Una vez que el contenido está aprobado y por tanto copiado en Main, se ejecutan las canalizaciones de compilación y despliegue de forma manual o automatica.
- Estas canalizaciones recuperan el contenido desde el repositorio y, mediante una libreria de python o con llamadas a las APIs, lo despliegan directamente en las áreas de pruebas y producción.
En este modelo, no existe una promoción entre entornos dentro de Fabric. Cada despliegue a Test o Producción es una acción explícita de la canalización externa, que aplica en cada entorno la versión exacta definida en Git.
Puedes ver el paso a paso de implementar esta solución con GitHub en este otro articulo.
Qué se despliega realmente en esta opción
A diferencia de la opción basada en canalizaciones de Fabric, aquí no se despliega una “foto” del área de desarrollo, sino una definición declarativa del estado deseado, almacenada en el repositorio.
Esto implica que:
- Solo lo que esté en la rama main puede llegar a producción.
- Los cambios no aprobados en Git no pueden desplegarse, aunque existan en el área de desarrollo.
- Git se convierte en el punto único de control y auditoría del proceso.
La consecuencia directa es que el despliegue deja de ser una decisión operativa en Fabric y pasa a ser una decisión técnica reflejada en el repositorio.
Mientras que en la opción basada en canalizaciones de Fabric la pregunta era “qué hay ahora mismo en el área de desarrollo”, en este modelo la pregunta pasa a ser “qué está aprobado en Git”. Este cambio de enfoque introduce mayor control y trazabilidad, pero también más pasos y mayor complejidad operativa.
Resumen de las tres opciones de despliegue en Microsoft Fabric
A lo largo del artículo hemos visto tres formas distintas de gestionar el despliegue entre entornos en Microsoft Fabric, cada una con un nivel diferente de control, complejidad y disciplina requerida. Ninguna es “mejor” en abstracto: la elección depende del contexto, del equipo y del grado de madurez en procesos DevOps.
Opción 1: Git como control de versiones y canalizaciones nativas de Fabric
Es el modelo más sencillo y el más habitual. Git se utiliza únicamente para versionar y auditar cambios, mientras que el despliegue se basa en el estado real del área de desarrollo y se ejecuta mediante las canalizaciones de Fabric. Su principal ventaja es la simplicidad y el bajo coste operativo, pero a cambio el repositorio no actúa como fuente de verdad del despliegue y la aprobación no queda reflejada explícitamente en Git.
Ventajas
- Simplicidad operativa
- Totalmente soportado por Fabric
- Ideal para empezar o para equipos pequeños
Desventajas
- Git no controla qué llega a producción
- Menor trazabilidad del proceso de aprobación
- Riesgo de desplegar cambios no validados en Git
Opción 2: Git como fuente de verdad con una única rama
Típica de enfoques trunk-based. Todo el trabajo converge en la rama Main, que actúa tanto como rama de desarrollo como de aprobación. El despliegue se ejecuta siempre desde Git mediante canalizaciones externas. Reduce pasos y fricción, pero exige un alto nivel de disciplina y control sobre la rama principal.
Ventajas
- Flujo más simple y directo
- Git como única fuente de verdad
- Menos ramas y menos gestión
Desventajas
- No adecuada para equipos grandes o poco maduros
- Menor separación entre trabajo en curso y aprobado
- Riesgo si no existen buenas políticas de rama
Opción 3: Git como fuente de verdad con dos ramas (Dev y Main)
En este modelo, Git gobierna el despliegue. La rama Dev representa el trabajo en curso y la rama Main el contenido aprobado. Las canalizaciones externas se ejecutan únicamente a partir de Main y despliegan directamente en Test y Producción usando una libreria de python. Ofrece mayor control y trazabilidad, a costa de más pasos y mayor complejidad.
Ventajas
- Separación clara entre desarrollo y aprobado
- Mayor control y auditoría
- Git define explícitamente qué se despliega
Desventajas
- Flujo más complejo
- Mayor carga de proceso
- Requiere disciplina en Git y CI/CD
Más allá de los escenarios habituales
Las opciones descritas en este artículo cubren los escenarios más comunes y prácticos a la hora de gestionar despliegues entre entornos en Microsoft Fabric, pero no representan todas las combinaciones posibles. Fabric permite una gran flexibilidad en la definición del proceso, y el modelo final puede variar en función de múltiples factores.
En primer lugar, la estrategia puede adaptarse al número de ramas utilizadas en Git. Aunque hemos visto ejemplos con una o dos ramas principales, es posible trabajar con estructuras más complejas que incluyan ramas por funcionalidad, por equipo o incluso por tipo de cambio, siempre que exista un proceso claro que determine desde qué rama se realizan los despliegues. Del mismo modo, el número de entornos no tiene por qué limitarse a desarrollo, pruebas y producción; pueden existir entornos intermedios, de validación técnica, de preproducción o incluso entornos efímeros asociados a pruebas concretas.
Además, en escenarios más avanzados, el grado de acoplamiento entre Fabric y Git puede reducirse aún más. Existen modelos en los que ningún área de trabajo está vinculada directamente a un repositorio, y donde todo el ciclo de vida se gestiona mediante canalizaciones externas. En este enfoque, Git actúa como repositorio puramente declarativo y las canalizaciones de CI/CD se encargan de crear, actualizar o eliminar los elementos en cada entorno utilizando las APIs de Fabric o librerias externas de python. Este tipo de arquitectura es habitual en organizaciones con un alto nivel de madurez DevOps, pero introduce una complejidad significativamente mayor.
También es posible combinar enfoques, por ejemplo utilizando Git integrado en el área de desarrollo para facilitar el trabajo diario, pero delegando los despliegues a entornos superiores en canalizaciones externas que reescriben configuraciones, conexiones o parámetros en función del destino. Estas variantes permiten adaptar el proceso a requisitos específicos de seguridad, cumplimiento o gobierno del dato.
En definitiva, no existe un único modelo válido para todos los casos. Las opciones presentadas en este artículo deben entenderse como patrones de referencia, a partir de los cuales cada organización puede construir su propio flujo en función del tamaño del equipo, el nivel de control requerido y la complejidad del entorno. Lo importante no es la herramienta elegida, sino que el proceso sea coherente, entendible y sostenible en el tiempo.
Conclusion personal
La gestión de despliegues entre entornos en Microsoft Fabric es un tema más complejo de lo que puede parecer a primera vista, especialmente si se intenta aplicar de forma directa modelos clásicos de CI/CD provenientes del desarrollo de software. Fabric introduce una separación clara entre el estado del workspace, el control de versiones en Git y los mecanismos reales de despliegue, y entender esa separación es clave para diseñar un flujo coherente.
A lo largo del artículo hemos visto que no existe una única forma “correcta” de trabajar con Git y Fabric. Las canalizaciones nativas de la plataforma priorizan la simplicidad y el control operativo, mientras que los modelos basados en CI/CD externo permiten que Git se convierta en la fuente única de verdad, a costa de mayor complejidad y responsabilidad técnica. La elección entre una o varias ramas, o incluso entre vincular o no los workspaces a Git, no responde a una limitación de la herramienta, sino al nivel de gobierno y madurez que se quiera implantar.
Uno de los puntos más importantes a interiorizar es que Git y Fabric juegan roles distintos. Git controla cómo se desarrolla y se aprueba el contenido; Fabric controla qué se ejecuta realmente en cada entorno. Confundir estos planos suele llevar a arquitecturas innecesariamente complejas o, por el contrario, a procesos demasiado laxos que dificultan la trazabilidad y el control.
Por último, conviene asumir que este no es un tema que se entienda de forma inmediata. Incluso para perfiles con experiencia en DevOps, Fabric introduce matices propios del mundo del dato que requieren cambiar el modelo mental. Por eso, más que buscar la solución “perfecta”, el objetivo debería ser diseñar un proceso claro, comprensible y sostenible, que el equipo pueda aplicar de forma consistente en el día a día.
En los próximos artículos se profundizará en ejemplos prácticos paso a paso, tanto con GitHub como con Azure DevOps, para mostrar cómo llevar estos modelos a la práctica y aterrizarlos en escenarios reales.
En Fabric, la pregunta no es qué herramienta usar, sino qué nivel de control y complejidad estás dispuesto a asumir.
