Fabric is Generally Available. Browse Fabric Presentations. Work towards your Fabric certification with the Cloud Skills Challenge.
Deployment Pipeline Experts,
I have a scenario where I have an active Production data set and dashboard where one of hte data sources is an excel file. That excel file was moved by an end user and they can't put it back to it's original location. As a result the dashboard is failing it's scheduled refresh. It's a pretty stratigh forward fix to deploy to dev, test and then production. However, I'm actively in UAT with testers on a version 2 of what's in production. The data set and the dashboard in UAT have the SAME NAME as the production dashboard and data set, "Workforce Dashboard". I don't want to impact my active UAT and want to deploy to production the version of Production with only the small fix immediately. I'm not using parameters or any deployment rules at the moment.
Question 1: What's the best method, without interrupting access for active end users in both environments, for fixing and deploying to production?
Thoughts...
- Could I rename the data set and dashboard in Power BI Service in Test and in UAT that represents version 2 to say "Workforce DashboardV2". Then download from PROD the old version, fix, load to Dev as Workforce Dashboard and migrate through test and production. Then go back and rename "Workforce DashboardV2" back to "Workforce Dashboard"?
-- I'm worried the rename will affect the share link or access in some way. If not, this may be my best solution.
- Any other thoughts
Question 2: is there any best practice I shoudl be using to make this easier in the future?
Thank you in advance.
Solved! Go to Solution.
Hi @bwarner87,
That's a good question. With our regular DWH releases and GIT, we have different branches from where we can deploy, which is obviously not the case with Power BI.. 😐
Depending on the number of actions you have to do to fix the bug, another option could be:
Hi @bwarner87,
Thanks for the detailed follow-up. I'm not sure why it did create 2 versions in Prod.
I'm glad you resolved the issue finally.
Hi @bwarner87,
That's a good question. With our regular DWH releases and GIT, we have different branches from where we can deploy, which is obviously not the case with Power BI.. 😐
Depending on the number of actions you have to do to fix the bug, another option could be:
@nickyvv ,
So after you communicated that the name change does not change the ID, I thought I was good with my shuffling name approach. However, this did NOT work and ended up creating 2 different reports and datasets with duplicate names in my production environment.
Here's what happened.
1. Changed my version 2 data set and dashboard names in Development from "Workforce Dashboard" to "Workforce Dashboardv2" and in Test from "Workforce Dashboard" to Workforce Dashboardv2.1" (it wouldn't let me use same file name for dev and test for the same PBIX which was interesting)
2. Downloaded "Workforce Dashboard" PBIX file from Production Workspace from my deployment pipeline.
3. Changed the file name to "Workforce Dashboard (Prod fix)"
4. Edited the file to update the connection URL For the SharePoint Excel file
5. Applied changes which refreshed the data in the PBIX. All looked good.
6. I changed the name of the PBIX from "Workforce Dashboard (Prod fix)" back to "Workforce Dashboard" the exact same name as production.
7. I published to Development workspace in my deployment pipeline so that now a dataset and dashboard with "Workforce Dashboard" and "Workforce Dashboardv2" existed.
8. I pressed "Deploy to test" and deployed. Now a dataset and dashboard with "Workforce Dashboard" and Workforce Dashboardv2.1" existed. I had to update my gateway for my sql data source but then verified "Workforce Dashboard" looked good.
9. I pressed "Deploy to production" and then to my surprise I had 2 datasets and 2 dashboards both with the "Workforce Dashboard" name. I thought because the ID would not change with a filename change this wouldn't happen, but it did and not sure why. (See below)
Ultimately to fix the problem i deleted all the "Workforce Dashboard" datasets and dashboards i had published or promoted in the steps above. I then took the same file I had edited the data source and instead published stratight to production, per your suggestion. It prompted me about the same file name warning me it would overwrite (which i wanted) and published. All is well now. I didn't try this method first because it's advised never to publish straight to production without testing first. But i was able to test with the other deployment mishap.
Other option: one thing I did notice is deployment options in PROD would have let me change the data source when deploying to PROD and I could have pasted in the new URL there without changing the PBIX directly. However i would have had to download and deploy through UAT and then PROD to do this and not ideal i think for future versions (see image)
I hope this helps someone else (if it does kudos me!)
Brandon
Check out the November 2023 Power BI update to learn about new features.
Read the latest Fabric Community announcements, including updates on Power BI, Synapse, Data Factory and Data Activator.