Best Practices for continuous deployments

[FireFighter1017]

Hi,

I don't have a lot of experience with CI/CD best practices, and I'm looking for help resolving some risks we have with our current process flow.

We currently have Github integration and deployment pipelines implemented to produce the following CI/CD flow for management of dataset, dataflow, report and dashboard artefacts in Power BI Service:

| Power BI Desktop |                    Power BI Service                                      |
|------------------|--------------------------------------------------------------------------|
Git ===> Github ====> Dev Workspace => QA Workspace => Production Workspace => Production App |

We're running into situations where some modifications to certain models are taking so long we can't make any bug fix to reports or the model itself.  Or we want to give the users a taste of a modification, but because they only see what's in the production app, we have to deploy everything to Prod.

Which can cause sometimes problems because we want to "beta test" a new page in an existing report but not necessarily make it available to all users at the same time.

I was wondering if any of you have developped a CI/CD flow or best practice, or faced the same challenges.

In the past, we have published an app in DEV and made it available to test users but that means the modifications will need to be reverted back through Git first if anything comes up.  And it jams the development of any patches for the artefact concerned.

I also thought of providing access to pbix files but that poses another challenge where users will be able to change the report/model and could make it difficult to provide any kind of support.

Another option would be to publish the modifications using power BI desktop instead of git integration, that would allow us to test a version and roll it back whenever we need using the git integration's "undo changes" button.

What do you do?  Are there any other methods to avoid conflicts?

[FireFighter1017 · Accepted solution]

Thanks @GeraldGEmerick ,

Following your recommendation I ended up with this flow:

 Sandbox Workspace ==> GitHub ==> Dev Workspace ==> QA Workspace ==> Prod Workspace ==> App 

Sandbox Workspace: Will serve for any development that we're not sure will make it to production and will serve as a beta testing because I will create an app and publish it only to users enrolled in beta testing and it will contain only the elements we wan't to test.  Once tests are done and we want to publish teh results, we will use the git Integration to export the artefacts to Github, in the same repo the Dev Workspace is connected to.

Github: We will be able to export anything done in the Sandbox Workspace to github and then import it in the Dev Workspace when we're ready to roll it out to QA & Prod.

Dev Workspace: Used to support and create artefacts that are to be deployed in QA & Prod.  Artefacts are updated using Git Integration, with the exception of Dataflows, which will be developped and maintained here, then exported to Github through Git integration for Gen2 and JSON files for Gen1.

QA Workspace: Used to test deployments before going to production.  We will do functional testing there to make sure we have not missed anything during deployment.

Prod Workspace: Closed and protected environment.  Nothing maintained here except through deployment pipelines

App: General access to artefacts for end users.

Let me know what you think.

[R1k91]

following @GeraldGEmerick suggestion, have you already considered to link the dev environment with your main branch using Fabric Git integration? Get started with Git integration - Microsoft Fabric | Microsoft Learn

Git integration workspaces - Microsoft Fabric | Microsoft Learn
with this approach you should be able to branch directly in Fabric, this creates a new workspace and link it to the branch. you can do changes in that workspace/branch and let users test it without touching the "main dev" worskpace/branch. when you are ready PullRequest on main and DEV will be aligned with changes ready to be pushed to TEST and then PROD via Deployment Pipelines.

[v-priyankata]

Hi @FireFighter1017 

Thank you for reaching out to the Microsoft Fabric Forum Community.

@Shahid12523 @GeraldGEmerick Thanks for your inputs.

I hope the information provided by users was helpful. If you still have questions, please don't hesitate to reach out to the community.

[Shahid12523]

• Workspaces separation → Dev → QA → Prod.
• Deployment Pipelines → promote content with rules & rollback support.
• Git branching → feature branches for new pages, hotfix branches for urgent fixes, main = Prod.
• Beta testing → QA app for test users or use App audiences to show new pages only to pilots.
• Version control → use Tabular Editor / pbi-tools, not just PBIX files.
• No direct Prod publish → always deploy via pipeline/Git for rollback.

[GeraldGEmerick]

@FireFighter1017 Something you might try is to have an alternate workspace that is outside of the normal CI/CD pipeline. Basically, for any prototyping, you deploy the Power BI file to this prototype workspace and collect feedback from users that you then use to integrate into the normal CI/CD pipeline.