Trabajar con Power BI en un entorno profesional implica mucho más que crear informes y dashboards. Cuando varios desarrolladores trabajan sobre el mismo proyecto, aparecen retos habituales: cambios que se sobrescriben, versiones difíciles de recuperar, falta de trazabilidad o dificultad para saber exactamente qué ha cambiado entre una versión y otra.
El problema empieza, en buena medida, con el formato .pbix.
Un archivo PBIX funciona muy bien para crear, compartir y distribuir informes, pero no está pensado como un formato de desarrollo colaborativo basado en control de versiones. Al tratarse de un archivo binario, Git puede detectar que ha cambiado, pero no interpretar fácilmente qué parte del modelo o del informe se ha modificado.
Con Power BI Project (PBIP), TMDL, Git y Microsoft Fabric, este escenario cambia.
Las definiciones del modelo semántico y del informe se almacenan como archivos de texto organizados en carpetas, lo que permite aplicar prácticas habituales del desarrollo de software: ramas, commits, diferencias de código, Pull Requests, revisiones y procesos de CI/CD. Microsoft define precisamente los proyectos PBIP como una forma de trabajar con Power BI mediante archivos compatibles con el control de código fuente.
En este artículo repasamos qué es PBIP, qué aporta frente a PBIX y cómo conectarlo con Git y Azure DevOps para construir un flujo de desarrollo más controlado y colaborativo.
De PBIX a PBIP: el cambio que necesita el desarrollo profesional de Power BI
El formato .pbix concentra en un único archivo buena parte de la información necesaria para trabajar con un informe de Power BI. Esto resulta práctico para determinados escenarios, pero presenta una limitación importante cuando queremos utilizar Git como sistema de control de versiones.
Imaginemos que un desarrollador modifica una medida DAX.
Git puede detectar que el archivo .pbix ha cambiado, pero no ofrece una comparación sencilla y granular del cambio realizado. No resulta fácil identificar qué medida se ha modificado, qué relación se ha añadido o qué propiedad del modelo ha cambiado.
En un entorno colaborativo, esto dificulta:
- Revisar cambios antes de incorporarlos.
- Identificar quién modificó un elemento.
- Recuperar versiones anteriores.
- Trabajar en paralelo.
- Resolver conflictos.
- Automatizar procesos de validación y despliegue.
PBIP cambia la unidad de trabajo.
En lugar de tratar el proyecto como un único archivo binario, Power BI Desktop almacena las definiciones del informe y del modelo semántico en una estructura de carpetas y archivos de texto.
De esta forma, el proyecto puede gestionarse mediante Git de una manera mucho más parecida a cualquier otro desarrollo de software.
¿Qué es Power BI Project (PBIP)?
Power BI Project (PBIP) es un formato de proyecto de Power BI Desktop diseñado para separar las definiciones de un informe y su modelo semántico en archivos individuales.
La estructura puede incluir, entre otros elementos:
MiProyecto/
├── MiProyecto.pbip
├── MiProyecto.SemanticModel/
│ └── definition/
├── MiProyecto.Report/
│ └── definition/
└── .gitignoreEl archivo .pbip actúa como un punto de entrada al proyecto, mientras que las carpetas contienen las definiciones necesarias para trabajar con el informe y el modelo semántico.
Esto permite que Git deje de trabajar únicamente con un archivo binario y pueda gestionar las distintas piezas del proyecto.
Y aquí aparece uno de los elementos clave de esta arquitectura: TMDL.
TMDL: hacer que el modelo semántico sea legible para Git
Tabular Model Definition Language (TMDL) es el formato utilizado para representar la definición del modelo semántico dentro de un proyecto Power BI.
A diferencia de TMSL, que utiliza un único archivo JSON de gran tamaño, TMDL organiza la definición del modelo en diferentes archivos y carpetas. Microsoft lo ha diseñado específicamente para facilitar la legibilidad, edición y colaboración.
Por ejemplo, el proyecto puede contener archivos específicos para tablas, relaciones, culturas o medidas.
Una medida DAX podría representarse de forma similar a:
Si esa medida cambia, Git puede identificar el cambio en el archivo correspondiente.
El resultado es importante: el control de versiones deja de limitarse a saber que “Power BI ha cambiado” y pasa a mostrar qué definición del proyecto ha cambiado.
Esta estructura facilita además el trabajo paralelo y la revisión de cambios mediante git diff y Pull Requests.
PBIP vs. PBIX: ¿cuándo utilizar cada formato?
No se trata simplemente de sustituir un formato por otro en todos los escenarios.
El .pbix continúa siendo útil para determinados casos, como prototipos, pruebas rápidas o desarrollos individuales.
Sin embargo, cuando hablamos de proyectos empresariales, equipos de desarrollo y soluciones que evolucionan en el tiempo, PBIP ofrece ventajas claras.
| Escenario | Formato recomendado |
| Prototipo rápido | .pbix |
| Informe individual | .pbix |
| Demo o prueba de concepto | .pbix |
| Desarrollo en equipo | PBIP |
| Control de versiones | PBIP + Git |
| Revisión mediante Pull Requests | PBIP + Git |
| Automatización CI/CD | PBIP + Azure DevOps/Fabric |
La propia documentación de Microsoft orienta PBIP hacia escenarios de desarrollo, control de código fuente y colaboración.
Cómo convertir un proyecto PBIX a PBIP
El primer paso para adoptar este modelo es convertir el proyecto existente.
Actualmente, Power BI Desktop permite guardar el trabajo como Power BI Project (.pbip). Para trabajar con determinadas funcionalidades de desarrollo, es necesario habilitar las características correspondientes en Archivo → Opciones y configuración → Opciones → Características en vista previa. Microsoft mantiene actualmente estas capacidades en evolución y algunas continúan en versión preliminar.
Una vez habilitado el formato:
- Abre el .pbix en Power BI Desktop.
- Selecciona Archivo → Guardar como.
- Selecciona Power BI Project (.pbip).
- Elige la carpeta donde almacenar el proyecto.
- Guarda el proyecto.
Power BI Desktop generará la estructura correspondiente al proyecto.
Una de las ventajas es que el PBIX original no tiene por qué desaparecer inmediatamente. Puede mantenerse como referencia durante la transición, aunque conviene definir desde el principio qué archivos deben formar parte del repositorio y cuáles deben quedar excluidos.
¿Qué ocurre con el modelo semántico?
Cuando el proyecto utiliza TMDL, la definición del modelo semántico se almacena en una carpeta definition, en lugar de concentrarse en un único archivo model.bim.
Microsoft explica que esta estructura permite separar las definiciones de tablas, perspectivas, roles y culturas, facilitando la lectura y el trabajo colaborativo con Git.
Además, Power BI Project puede incorporar otras estructuras para representar el informe. Con PBIR, por ejemplo, páginas, objetos visuales y otros elementos pueden organizarse en archivos independientes, facilitando todavía más el seguimiento de cambios y la resolución de conflictos.
Esto abre una puerta especialmente interesante para los equipos de Data:
Power BI empieza a comportarse mucho más como un proyecto de software que como un archivo aislado.
Conectar PBIP con Git y Azure DevOps
Una vez creado el proyecto PBIP, el siguiente paso es incorporarlo a un repositorio Git.
Para organizaciones que ya utilizan el ecosistema Microsoft, Azure DevOps ofrece una integración especialmente interesante con Power BI y Microsoft Fabric.
El proceso básico consiste en:
- Crear un proyecto en Azure DevOps.
- Crear o inicializar un repositorio Git.
- Clonar el repositorio localmente.
- Guardar el proyecto PBIP dentro del repositorio.
- Hacer el primer commit.
- Publicar los cambios en Azure DevOps.
Microsoft documenta específicamente este flujo para proyectos de Power BI Desktop: crear el repositorio, clonarlo mediante VS Code, guardar el proyecto PBIP y realizar el commit y la sincronización.
Una estructura sencilla podría ser:
MiRepositorio/
├── README.md
└── MiProyecto/
├── MiProyecto.pbip
├── MiProyecto.SemanticModel/
└── MiProyecto.Report/
A partir de aquí, el proyecto ya puede gestionarse mediante Git.
El verdadero valor: los cambios empiezan a ser trazables
Aquí es donde PBIP demuestra realmente su valor.
Imaginemos que un desarrollador modifica una medida DAX:
measure ‘Total Sales’ = SUM(Sales[Amount])
y posteriormente cambia su definición:
Con un proyecto basado en archivos de texto, Git puede mostrar la diferencia entre ambas versiones.
Esto permite saber:
- Qué ha cambiado.
- Quién ha realizado el cambio.
- Cuándo se ha realizado.
- En qué archivo se encuentra.
- Qué versión existía anteriormente.
Y, sobre todo, permite revisar el cambio antes de incorporarlo al código principal.
Ese es el salto conceptual: el control de versiones deja de ser una copia de seguridad y se convierte en una herramienta de desarrollo.
Ramas y Pull Requests: Git aplicado a Power BI
Una vez que el proyecto está en Git, el equipo puede aplicar una estrategia de ramas similar a la utilizada en otros proyectos de software.
Por ejemplo:
El desarrollador trabaja sobre su rama y, cuando termina, crea un Pull Request hacia main.
Otro miembro del equipo puede revisar entonces los cambios antes de aprobarlos.
En lugar de recibir simplemente un nuevo .pbix, el equipo puede revisar qué medidas se han modificado, qué relaciones han cambiado o qué elementos del informe se han actualizado.
Microsoft contempla precisamente este escenario dentro de la integración de proyectos PBIP con Azure DevOps.
Microsoft Fabric: llevar Git más allá del entorno local
La integración no tiene por qué terminar en Power BI Desktop.
Microsoft Fabric permite conectar un workspace directamente con un repositorio Git, incluyendo repositorios de Azure DevOps.
Desde la configuración del workspace se puede establecer la conexión con el proveedor Git, seleccionar la organización, proyecto, repositorio y rama correspondientes y sincronizar el contenido.
Esto permite construir un flujo bidireccional:
Power BI Desktop → Git → Fabric
y también:
Fabric → Git → Power BI Desktop
El resultado es una arquitectura mucho más cercana a un verdadero ciclo de vida de desarrollo.
De Git a CI/CD: el siguiente paso
Una vez que PBIP, Git, Azure DevOps y Fabric están conectados, aparece una posibilidad especialmente relevante para organizaciones con procesos de desarrollo maduros: automatizar la integración y el despliegue.
Los cambios pueden pasar por ramas, Pull Requests y validaciones antes de llegar al entorno de producción.
Microsoft documenta la utilización conjunta de PBIP, Azure DevOps y Azure Pipelines para construir procesos de CI/CD capaces de validar los metadatos de los proyectos antes de su despliegue.
El flujo puede evolucionar hacia un modelo como este:
Power BI Desktop
↓
Feature branch
↓
Git
↓
Pull Request
↓
Validaciones / CI
↓
main
↓
Microsoft Fabric
↓
Producción
Y esto cambia por completo la forma de entender el desarrollo de Power BI.
Ya no hablamos únicamente de crear informes. Hablamos de gestionar el ciclo de vida de una solución de datos.
Limitaciones y aspectos que conviene tener en cuenta
Adoptar PBIP + Git aporta muchas ventajas, pero no significa que todos los problemas de desarrollo desaparezcan.
No todos los elementos tienen el mismo nivel de soporte
La integración de Git de Fabric continúa evolucionando y existen diferencias entre los elementos que pueden integrarse y sincronizarse. Por ello, antes de definir una arquitectura de producción conviene revisar la documentación actualizada de Microsoft.
Los conflictos no desaparecen
Trabajar con archivos de texto facilita los diff, pero no elimina los conflictos de merge.
La definición del informe puede ser especialmente sensible cuando varias personas modifican simultáneamente los mismos elementos. Una estrategia adecuada de ramas y responsabilidades sigue siendo fundamental.
Hay que definir una estrategia Git
Adoptar PBIP no consiste simplemente en guardar los archivos en un repositorio.
Es necesario definir:
- Estrategia de ramas.
- Convenciones de commits.
- Pull Requests.
- Revisiones.
- Políticas de main.
- Procesos de validación.
- Gestión de entornos.
- Estrategia de despliegue.
La tecnología habilita el cambio, pero el proceso es el que hace que funcione.
PBIP + Git + Fabric: una nueva forma de desarrollar Data & BI
El salto de PBIX a PBIP puede parecer inicialmente un cambio de formato.
En realidad, es mucho más que eso.
PBIP convierte Power BI en un proyecto estructurado. TMDL hace que el modelo semántico sea más legible y manejable. Git aporta control de versiones y colaboración. Azure DevOps permite incorporar procesos de desarrollo y CI/CD. Y Fabric conecta todo ello con el entorno de datos y analítica.
El resultado es un modelo de trabajo más cercano al que los equipos de ingeniería ya utilizan en otros desarrollos tecnológicos.
Tres ideas resumen este cambio:
- El control de versiones importa en Power BI.
Cuando una solución de datos es crítica para el negocio, saber qué ha cambiado y poder recuperar una versión anterior deja de ser opcional. - PBIP facilita el trabajo colaborativo.
La separación de las definiciones en archivos de texto permite revisar cambios, trabajar con ramas y utilizar Pull Requests. - PBIP es el punto de partida para una estrategia de CI/CD.
La integración con Azure DevOps y Microsoft Fabric permite avanzar desde el desarrollo manual hacia procesos de validación y despliegue mucho más automatizados.
En definitiva, si Power BI forma parte de una plataforma de datos empresarial, el control de versiones debería formar parte también de su ciclo de desarrollo.
Y PBIP + Git es uno de los caminos para conseguirlo.
¿Quieres descubrir qué puede hacer PBIP + Git por tu negocio?
Si tu organización trabaja con Power BI a escala empresarial, dar el salto a PBIP y Git puede ser mucho más que una mejora técnica: puede ayudarte a trabajar de forma más colaborativa, controlar mejor los cambios y sentar las bases de un desarrollo de BI más ágil y automatizado. En Bravent podemos ayudarte a entender cómo encaja este enfoque en tu entorno, qué oportunidades puede aportar a tu equipo y cómo aplicarlo a tus proyectos reales. Hablemos: info@bravent.net
En definitiva, si Power BI forma parte de una plataforma de datos empresarial, el control de versiones debería formar parte también de su ciclo de desarrollo.
Y PBIP + Git es uno de los caminos para conseguirlo.
