Power BI collaborative development
allows multiple developers to work collaboratively on the same PBIX.
Idea could be separate back-end (advanced editor) and fron-end (modelling and report design) or allows the possibility to merge more than one pbix.
Also a separation of data and code: can already be done somewhat with .pbit (and you can diff a .pbit) but that is far from satisfactory and not easy to automate. Would much prefer for the Power Query M commands to be able to act server side in development (perhaps dataflow heading this way but doesn't help right now as not part of refresh).
Report design already separated from model by getting data from BI Service so that part of collaborative development not an issue for us.
Being able to follow dev cycle practices like manage in source control and look at code (to compare versions, manage settings and parameters that are scattered through UI) would be a game changer. Power BI will have massive adoption once it wins over the developer community, and all it needs to do is open up the code and allow creation of internal variables, functions, to provide the developer greater ability to refactor.
Collaboration is the essence of team work, so far I have found Power BI to be lacking in this big time. We tried publishing to the service to collaborate but lo & behold the calculated measures do not come through and dev features are limited in the online version.
Guido de Vries commented
Power BI would be nearing perfect if it could be used in a collaborative environment. Merging, source control, version control, deployment control, everything.
These concepts have been worked out allready through Agile DevOps, and this should be integrated so that you can manage it all in one place. This should be the next step for PowerBI's journey in conquering the Microsoft BI world. Microsoft, make this happen!
Dan Robbins commented
You can already decouple the data from the visualizations. (see below)
Having the ability to DIFF PBIX files and MERGE changes would be very helpful.
1. Perform all of your Data Modeling (Power Query M and DAX) in one PBIX file.
2. Publish it to the Power BI Service.
3. Open a new Reports PBIX file, select Power BI -> Power BI datasets as your data source.
You can also add additional DAX to the Reports PBIX file.
This allows versioning of the Dataset and building Reports tailored to different audiences.
The Report PBIX files are ### KB while the Dataset PBIX files are ###,### KB or larger.
You can decouple your ETL (Power Query M) & Model (DAX) from the Report definition using Analysis Services Tabular. If you have an Azure AS instance, you can even deploy the ETL & Model portion of a .pbix directly to it. This may not be an option for smaller organizations, as Analysis Services is far from free, but to those who can...
The good: IT can govern the semantic model and still provide a lot of reporting flexibility to end-users.
The bad: Analysis Services models at the 1400 compat-level are still crammed into a single-file .bim file... not a good thing for your VCS.
The ugly: The Analysis Services tooling in SSDT for Visual Studio feels a bit abandoned. They ported the Power BI "Get Data" experience into SSDT a while back, which is great, but Power Query Groups are broken/unimplemented, making managing the ETL for larger projects a nightmare.
Great Idea. It should also allow us to use version control systems in order to keep up with the changes everyone has made
Jeroen Habets commented
Or even better: a proper integration with source control (e.g. git). An integration is proper when you the files are text so you can diff (= view differences).
Please allow the possibility to merge more than one PBIX in order to collaborate effectively with colleagues during developments. It's needed