October 28 & 29: Experts share their secrets on how to pass the Fabric Analytics Engineer certification exam—live. Learn more
I am looking for a streamlined way to move a Power BI project through the software development life cycle. Taking the data source references in a PBIX from dev to test to prod without any manual intervention but possibly doing something a bit more dynamic. Has anyone spent anytime on this are are we still too early to have seen this 'enterprise' adoption.
Solved! Go to Solution.
I have spent some time doing this for customers. Thus far it has been a bit frustrating. I have had some limited success in simply editing the underlying data source to change it from dev to prod for example, but have run into problems as well. Generally, the problem is with adding calculated columns. Simply stated, if you hope for this to work, minimize or eliminate your use of custom columns and possibly measures, they often seem to cause problems when you swap data sources under the hood. You end up putting a lot more of this in M if at all possible, which makes your M code a lot more complex.
The really frustrating part with this is that you have to blow away the underlying data table and recreate it, which wipes it out of all of your visualizations, breaks relationships, it's really kind of a real mess.
One comment that I have on this because of the frustrations that I have had, if you can use prod as your starting point for your data model, by all means do that. I realize that this is not always possible because you are often changing the underlying data in dev or need stored procedures written, etc. but if that is not the case, use prod data, it's not like the load of data from prod into your model is a big performance hit on prod and you could limit the amount ingested at first and then remove that limit when your model goes to production.
@bobrin My experience with Enterprise related implementations revolve around utilizing Tabular models. Alot of the pain of changing parts of the model in the PBIX files goes away when you are direct connecting to a SSAS instance.
If you have the option, I would say, it is currently the best way to implement an enterprise level implementation.
A couple ways to implement would be to have one prod SSAS instance and use Groups to manage Dev/Test/Prod
Or have multiple SSAS instances. From my understanding, there should be no issue switching environments as long as the model name is the same.
All implementations I've done, start by using the Desktop - so I have "backups" of the reports, then pulling those files into the appropriate groups and creating dashboards/sharing if applicable.
Store those Desktop versions in TFS / One Drive / or some central location for backup/version control..
At this point, I think we all look forward to more Enterprise level features, and for right now it really comes down to creating a managed process that works for your implementation.
I have spent some time doing this for customers. Thus far it has been a bit frustrating. I have had some limited success in simply editing the underlying data source to change it from dev to prod for example, but have run into problems as well. Generally, the problem is with adding calculated columns. Simply stated, if you hope for this to work, minimize or eliminate your use of custom columns and possibly measures, they often seem to cause problems when you swap data sources under the hood. You end up putting a lot more of this in M if at all possible, which makes your M code a lot more complex.
The really frustrating part with this is that you have to blow away the underlying data table and recreate it, which wipes it out of all of your visualizations, breaks relationships, it's really kind of a real mess.
One comment that I have on this because of the frustrations that I have had, if you can use prod as your starting point for your data model, by all means do that. I realize that this is not always possible because you are often changing the underlying data in dev or need stored procedures written, etc. but if that is not the case, use prod data, it's not like the load of data from prod into your model is a big performance hit on prod and you could limit the amount ingested at first and then remove that limit when your model goes to production.