@Rens There are other ways than what I use as my process, but this is what I do.
Summary is:
-
Communicating the plan for updating in a shared environment
-
Separating into “data model” pbix and “visualizations” pbix files. The “visualizations” pbix live connect to the published “data model” pbix. This allows for a division of labor, re-usability, and single source of truth.
- DevOps Repo, or some sort of master source control that gives merge conflicts, commenting, version history.
- Workspace/App
-
Dev Workspace/App and Prod Workspace/App (especially when your “data model” pbix has connections to many reports!)
-
Power BI release pipelines (premium), this automates and gives excellent options on parameterization of servers and what you want to move from one environment to another. Syncs between Dev, Test, and Prod Workspaces/Apps.
Communicating is key in working in a shared Power BI environment. Make sure everyone knows the established process, and when working on specific files let everyone else know. You can talk in person in say a daily stand up, create a channel in teams or slack, whatever works best with your team.
My typical process is:
Get changes from source control > let others know I’m in x file making y changes > open file in synced folder > make changes > publish to workspace > validate > publish app > sync file back to source control > let others know I’m done.
What is critical is that if someone, for example, chooses to simply edit the report in the browser and save it, I will overwrite all those changes with this process. If someone deletes a file in the workspace on accident, I’m covered and can have the report back up in a few minutes.
Separating the pbix into a “data model” pbix and “visualization” pbix. This is automatically done actually whenever you publish a file too (content and dataset on the service), and I’m not advocating running every single report this way. It makes sense when you create a main data model that will feed multiple different reports. I usually start off in one pbix and then when am not making as many data model changes (creating measures, bringing in data) then I publish it. Then create a new pbix live connected to published dataset, then simply copy the visuals I may have started into the new one. If you have bookmarks and such that don’t copy that way, then copy the original file (or save as) and then remove all the tables of data. Then you can connect to the published dataset. Now you can have people working on new reports or editing existing reports, and have someone maybe making new measures on the data model all in parallel at the same time. You do have to be careful now with your shared data model, as it will have impact on many downstream reports. Table name changes, column name changes should be done as translations not renames for example.
For Source Control I prefer devops repo as we have to be working out of devops for user stories anyway. You just need somewhere to store “master” copies of the pbix files that you work in then publish. Ideally with merge conflict notification, version history, and commenting. And a process for syncing. This is also super important for incremental refresh models. When I modify the pbix file for incremental refresh I utilize alm toolkit to push changes to the service instead of publishing from power bi desktop as to not mess up partitioning.
When publishing from power bi desktop you do so to a shared workspace (not your my workspace) that multiple people can access and publish to. This really for content creators. You can also give read access here to other people if you want to, maybe for internal team only reports. This can be thought of as “draft”. You can then pick and choose which reports you want to publish to an app. This can have many more people as readers that aren’t allowed to see the workspace versions of the reports. It can also be entire organization. Then a copy is published to that app. They are two versions with different GUIDs in the urls.
If you have many reports you can take that another step further as you said, and have a dev and prod version of the workspace/app. First going to dev, checking everything or giving stakeholders a preview for feedback, then pushing to prod.
And if you have premium there is a formalized release pipeline for that dev/test/prod workspace/app scenario. It has many very cool features and easy to use. Power BI Application lifecycle management (ALM) deployment pipelines overview - Power BI | Microsoft Docs
I use this process even when I am a team of one because things happen on the service sometimes and computers can fail.
Hope this helps!
Respectfully,
DataZoe
