Forum Discussion
Issues with Power BI CI/CD using PBIP format, Direct Lake, Git Integration, and Deployment Pipelines
- 1 year ago
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!!
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 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!!
- IvanGennaro1 year agoRegular Visitor
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:
- IvanGennaro1 year agoRegular Visitor
Hey! Thanks v-sathmakuri for your suggestions! I've tested it and it worked. It is definitelly possible to use git to move the reports across Fabric and Deployment Pipelines for Models while maintaining a Direct-Lake connection.
Even though it worked, we still went for a more simplistic approach because the full-fledge git ci/cd approach was adding too much complexity for our use case. We moved to a Fabric-centric approach, using the "Publish report" method and Deployment pipelines to move the reports and models across nonprod and prod workspaces. The only part that we want to rely on pure Git is for report distribution across functional workspaces, we would have our Report-Production workspace with all our reports, but we need to distribute copies of those in functional/department workspaces for business users to consume. All of them will be pointing to the production model in report-production ws.
There is also a bit more information on my reddit post regarding this topic: https://www.reddit.com/r/MicrosoftFabric/comments/1kmhx09/issues_with_power_bi_cicd_using_pbip_format/
This is how our final approach looks: