Need a way to test a dashboard before releasing to production.
Need a way to test a dashboard (some sort of a dev environment) before releasing (to production environment). This is especially critical in enterprise settings, where any change to the dashboard will likely have large business impact affecing a large number of people.
We’re doing several improvements to the overall manageability, collaborative authoring, and organization of dashboards/reports. Having a pre-release test environment is a key component of the forward roadmap.
Is there a timeframe for a preview release/GA of this feature?
There needs to be a way in the Power BI service to configure multiple 'environments', to allow iteration through these as part of any integration test/UAT/pre-prod/Prod deployment pipeline.
Many of our clients are looking to us for guidance on best practices around Power BI release & configuration management and this is a significant omission at present,
particularly for clients in verticals where regulatory compliance reporting and change control processes are intertwined and is an impediment to wider adoption.
Peer Grønnerup commented
This cannot be done by using content packs. I we change a connection string from i.e. production to test in a PBIX file and re-publish it the change in the connection string will be applied to the content pack. It looks like the update function for content packs only applies to dashboards, reports and datasets. Not the the connection strings them selves.
Any time frame/date by which this pre-release test environment will be released?
Mostly the developers would be developing the reports based on junk data or a snapshot of production / UAT instance. And if a report is published as such, it wouldn't point to production. Developing on production instance again is not an option ( ISMS issues ).
Before deploying, there should be an option to configure against the production. Or the connection string configurable as required.
You can do this with org content packs, no? You can edit a dashboard, but a recipient will see it only after you update the content pack.
Christopher Woodward commented
I would suggest creating a new Outlook Group and only add the test users into it. Then when you publish a content pack, you can subscribe only that Outlook group to the pack to test.
Michael Steineke commented
Changing datasource and copy/export the report/dashboard would both be useful for dev lifecycle. Permissions on who owns a report is also less that desirable
Achal Anjaria commented
May be you can add "publish" feature and versioning on objects like in SharePoint. Unless its published its in draft status not visible to those shared.
Daragh Fitzpatrick commented
Consider creating a 'beta'/draft site separate from 'release'/final. Yes, they're both in production, but consider that this is considered to be a self-service tool, not a developer tool - i.e., business users using production data directly. This requires an Agile methodology, does not allow for Waterfall, and specifically PROHIBITS SDLC which is the whole reason business doesn't want IT doing this.
Derrick Han commented
And a way to quickly change data source from UAT/TEST to PROD while maintaining the same data model and chart formatting will be extremely helpful. Currently, changing data source might destroy the data model created