Forum Discussion
Issues with Power BI CI/CD using PBIP format, Direct Lake, Git Integration, and Deployment Pipelines
Hi IvanGennaro ,
Thank you for reaching out to Microsoft Fabric Community.
I recommend the following approach for implementing a reliable CI/CD flow for PBIP reports in Microsoft Fabric:
Place your Direct Lake model in a shared workspace. Reference that shared model from all report workspaces (Sandbox, Dev, Prod). This avoids broken bindings when the model doesn’t exist in downstream workspaces.
Maintain Git branches like main, dev, and prod.
Each Fabric workspace syncs to its respective branch (e.g., Dev WS <-> dev branch).
Use Git pull requests (PRs) to promote code and control approvals.
Use Git as the source for reports. sync from Git in every workspace. Deployment Pipelines can be used for model promotion or basic stagingPBIP reports should include a connections.json referencing the datasetId and workspaceId (GUIDs), not just names.
This ensures the report knows where to find the dataset, regardless of workspace context.You can refer to the following Microsoft documentation for more details:
https://learn.microsoft.com/en-us/fabric/cicd/git-integration/manage-branches?tabs=azure-devops
https://learn.microsoft.com/en-us/fabric/cicd/best-practices-cicd
https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-git
If this post helps, then please consider Accepting as solution to help the other members find it more quickly, don't forget to give a "Kudos" – I’d truly appreciate it!
Thank you!!
Community SupportHi IvanGennaro ,
Thank you for reaching out to Microsoft Fabric Community.
I recommend the following approach for implementing a reliable CI/CD flow for PBIP reports in Microsoft Fabric:
Place your Direct Lake model in a shared workspace. Reference that shared model from all report workspaces (Sandbox, Dev, Prod). This avoids broken bindings when the model doesn’t exist in downstream workspaces.
Maintain Git branches like main, dev, and prod.
Each Fabric workspace syncs to its respective branch (e.g., Dev WS <-> dev branch).
Use Git pull requests (PRs) to promote code and control approvals.
Use Git as the source for reports. sync from Git in every workspace. Deployment Pipelines can be used for model promotion or basic staging
PBIP reports should include a connections.json referencing the datasetId and workspaceId (GUIDs), not just names.
This ensures the report knows where to find the dataset, regardless of workspace context.
You can refer to the following Microsoft documentation for more details:
https://learn.microsoft.com/en-us/fabric/cicd/git-integration/manage-branches?tabs=azure-devops
https://learn.microsoft.com/en-us/fabric/cicd/best-practices-cicd
https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-git
If this post helps, then please consider Accepting as solution to help the other members find it more quickly, don't forget to give a "Kudos" – I’d truly appreciate it!
Thank you!!
Hey! Thank you very much! I've tested your suggestions and it worked. It is certainly possible to move the reports through git while using deployment pipelines for the models.
Even though this worked well, we prefered going for a full fabric centric solution for Report and Model CI/CD using the "Publish" method and Deployment pipelines only while maintaining basic git integration (workspace level) for basic version control. We opted this approach because of the complexity of managing PBIP files and Git from a business user standpoint (aiming to self-service BI in the future) and managing different deployment processes for different objects from a maintainer perspective. We went for simplicity.
Disclaimer: We are still seeing some weird bugs in the Deployment rules GUI, Git syncs delays and other minor problems but it worked. We are not going full production yet so, we hope that the experience will get better sooner.
Our final CI/CD process for Power BI reports and models look something like this: