Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.

Reply
bwarner87
Advocate I
Advocate I

Production Bug Fix when actively in UAT using Deployment Pipeline

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.

1 ACCEPTED SOLUTION
nickyvv
Community Champion
Community Champion

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.. 😐

  • Changing the dataset name does not change the ID.

Depending on the number of actions you have to do to fix the bug, another option could be:

  • do the changes to the downloaded Prod file and publish to Prod
  • do the changes also in the other pipelines manually if necessary. You might be able to combine Dev+Test if that's your current UAT version. So change Dev and deploy that to Test.


Did I answer your question? Mark my post as a solution!

Blog: nickyvv.com | @NickyvV


View solution in original post

3 REPLIES 3
nickyvv
Community Champion
Community Champion

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.



Did I answer your question? Mark my post as a solution!

Blog: nickyvv.com | @NickyvV


nickyvv
Community Champion
Community Champion

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.. 😐

  • Changing the dataset name does not change the ID.

Depending on the number of actions you have to do to fix the bug, another option could be:

  • do the changes to the downloaded Prod file and publish to Prod
  • do the changes also in the other pipelines manually if necessary. You might be able to combine Dev+Test if that's your current UAT version. So change Dev and deploy that to Test.


Did I answer your question? Mark my post as a solution!

Blog: nickyvv.com | @NickyvV


@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)

Pipeline mishap.jpg

 

 

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)

 

Deployment Rules.jpg

 

I hope this helps someone else (if it does kudos me!) 

 

Brandon

Helpful resources

Announcements
Microsoft Fabric Learn Together

Microsoft Fabric Learn Together

Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City

PBI_APRIL_CAROUSEL1

Power BI Monthly Update - April 2024

Check out the April 2024 Power BI update to learn about new features.

April Fabric Community Update

Fabric Community Update - April 2024

Find out what's new and trending in the Fabric Community.

Top Solution Authors
Top Kudoed Authors