that's actually better because by moving through pipeline, other rules can be applied. In my set up I have dataset in a different pipeline so by moving them through matching stages, it pointd to the right dataset stages.
Hey! Great video! I think you should go a step further with Git + Deployment Pipelines integration. I found this was the best option for me and works smoothly. Also, if you could comment what kind of licence you need to implement each case would be great! Watch your videos all the time! You are amazing!
Plus , 1. The method shown here is a bit different from normal gitflow as far what I have seen, which starts from dev branch and creating a feature branch from there. Can it be done here also? Or we always need this initial file mode. 2. How will in a big organization the access control of those branches happen?
What I usually prefer is having just one development workspace hooked up with Git and using deployment pipelines to move from development to testing to production.
This makes sense to me. Since Dataflows are not yet supported in Git and the deployment pipelines automate pointing DF connections in the same workspace.
It would be great if you could announce in the video (near the start) or in the thumbnail if the content requires a premium or PPU sku so that us PRO scrubs needn't bother watching. Thanks
Should we use deployment pipelines in this process? For example, only push via git to the dev workspace and then use deployment pipeline to push up to the higher lifecycles? Is this not advised?
It's all great, but you skipped over one of the most important parts of all this - reviewing the actual pull requests. What I've found so far is that is not great, a bunch of random files that I don't necessarily understand. Thoughts on that?
I saw other video with some guys from MS saying that they are working on making project files more human readable, especially report layout but don't know when that is coming
yes, that sucks and make it almost un-reviewable. What I implement in my teams is to have the developing report published to a playground workspace for reviewing and light testing. Still wish the file is more readable but I doubt it is possible in the near future. Changes in dataset is somehow readable though, not easy but its acceptable.
love it, but waaaaaay to many bugs. Guys, it is BETA, so don't go all in to fast. I don't want to refresh my entire model (it's close to 1 billion rows) for minor changes to the tabels. ALM toolkit is still being used to bypass the bugs. Otherwise thumbs up
Let me know when you have a visual interface for GIT in your visual interface product. Nobody on our PBI teams uses GIT or has needed to. Going back to DOS land to manage PBI files.. blarg. If the *common practice for doing things* is rocket surgery, then it's a system ripe for disruption.
Using Visual Studio Code instead of powershell is an option but still a little too "techie" for an average user and requires multiple tools. I hope it gets easier and simpler.
Adam demoed the visual interface in the video at about 10:45 (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-zvyr2qYCQNo.htmlsi=9ZTCEECNYadgke-f&t=645). Is this not exactly what you're asking for?
@@KNP-BIIt's great IF you're working in Fabric. Fabric still isn't approved for our workflow because our DevOps folks are leery of MS dumping support for whatever flavor of hotness of the month is. Meanwhile, as demonstrated in the video there's no integration in the Desktop App, so we're still having to manually play around with PBIP solution folders on the network storage at which point Git is little more than a extra work to document why we have a dozen solution folders for 'branches'. FWIW, we're using GIT in VS. But there's no editor in VS for PBI, so it's just a glorified Synch tool.
Q: What if two developers are working on the same dashboard at the same time? Q: What if two reports are connected to the same model and we create new measures in both the reports then how will it work? Q: Will it work when we use a live connection to develop a new report? Just some quick questions. Great video!!!!
Disappointed. I thought pbix merge would come with this. That's the big deal we're waiting for. Without it, multiple people cannot work on the same report simultaneously. We need more granularity and fragmentation of pbix files.
I bet it will be just like the bad old days of visual studio - relevant semantic changes drowning in giant noisy random incomprehensible XML diffs for no good reason. Programming is (still) terrible...
Pull request conflicts can be solved in your local git, as one would solve other pull request conflicts when doing other type of development. If you have a feature branch and you get conflict on PR to main, rebase feature branch onto main branch (on the local git), resolve merge conflict , and then create PR again.
So many questions. -can we report on the commit messages like we can with GitHub? -is this functionality ideal for report source control? -I’ve been using Tabular Editor + TMDL + GitHub for semantic model source control - and I’m loving it. Could you walk through this process for a large dataset that is managed solely via XMLA endpoint?
That's cool!! Can you also do a follow up video on how to roll back to any of the previous commits no one have explained this any of the videos or blogs that would be really helpful
@@GuyInACube Actually in Azure DevOps is possible if you go to Repos->Pull requests, you can revert that one specific pull request you made in the past. I am still in kind of testing how this behaves wrt PBI so I might be wrong, but since this worked in the past for some "Descriptions" in the model, I assume this should work
Agree, would love to see how to rollback to a previous commit. Even better if this was a selection option within the workspace (submitting to idea place). Also, as others have mentioned, would like to see a good practice incorporating the deployment pipeline.
Thanks for the video. This is burdensome. Don't tell me we can't do this with native DevOps instead of Git? I mean, just Microsoft DevOps alone. Pull requests and all can be done through the browser instead of doing stuff through code in PowerShell or whatever.
How does this all integrate with deployment pipelines (if at all)? Would this be something that effectively replaces deployment pipelines, or do they work together somehow? Would love to see more videos on this and Microsoft's/your recommended best practices for how to best handle CI/CD in PBI/Fabric!
I think we use Git to push all changes into DEV but then use deployment pipeline to sync between DEV and PROD. It seems a lot of push and pulls syncing between DEV and PROD using GIT. I think can be simplified with a deployment pipeline between the 2 workspaces. My 2 cents.
well this is cool and long awaited! Thank you for the intro! @GuyInACube how do you make the terminal to display the branch in the path?! that is awesome
Hello, great video guys. Thanks ! Is this feature working only with import mode reports with semantic models ? I tried to do it with a report whose sources is Azure Analysis Services and got the following error. " Report Workload failed to DiscoverDependencies for DefinitionId =xxx since it failed to get the dependency from report definition part. Reports utilizing ‘byConnection’ reference must connect to Power BI hosted semantic models. Azure Analysis Services and SQL Server Analysis Services hosted semantic models are not supported. "
GIT integration with PBI is great. Once the git integration is done, i feel deployment pipelines is a great way to visually deploy multiple assets from dev to prod (in this case) as it is very intuitive. Only draw back is we dont have approval (PR) mechanism in deployment pipelines. Also one question is: can we restrict users to publish the report directly into prod (vial publish in PBI desktop) ?
@@GuyInACubeThanks for the video! Could you tell us how did you get the PowerShell color scheme (blue for the folder, yellow for the branch ...) ? Thanks a lot!
#guyinAcube - taking the same report holding the same connection string how can we deploy to prod with a different parameter? - since the PowerBI parameter is part of the report code - I didn't find a simple why to change the connection once we push to "main"/"prod" branch- any thoughts?
Nice video. 👊 What's the point of deployment pipeline? This seems like a better option just not as user friendly as the pipeline flow and more manual steps to check for differences. Also is the developer working on the pbip file and not pbix file? Is there any risk there
I couldn't agree more. Once they add automation like pulling the change automatically at the workspace or update Power Bi App... I won't see the point for deploment pipelines... This would be way better to keep control version of each environment.
Any ideas how this would work when a dev workspace pulls from a dev data warehouse? I can't see how this would work with git, but it seems integrated in deployment pipelines
I am currently using CICD on Azure DevOps with pbix and PBI API. I love that MS finally have PBIP so I don't have to use the pbix (binary file) on git. But the deployment method is kind of sub-par to me. As this vid shows, the roll back method is to add another commit. If you don't remember what you have changed, you have to go through all of the commits. I will stick with PBIX until PBI API supports publishing reports with PBI or MS allow to build PBIX from PBIP in a CLI fashion.
Hey Adam, first off, great video! Really helpful stuff. My question, is version control also possible in the Power BI service? We comment a lot in the reports as plain text, but overwriting each other's work is a problem for us. Thanks!
does this have limitation for reports using live connect ? my pbip file, which uses Live Connect to an on-premises SQL Server Analysis Services (SSAS) server, won't be synchronized through Git integration, it raise error that Failed to discover dependencies
What a great and useful watch! Thank you so much for this. I've got a question: given all the prerequisites, is it also possible for a multi-user collaboration work in PowerBI Web with Git? A report is in a shared workspace and the structure is as follows: each git branch is an isolated dev's work and they merge changes into the master to obtain the end report for prod. No matter what each dev is working at - a page, semantic layer, etc.
@GuyInACube I'm a little bit confused by the different options to manage deployments at this point. Should I use the paradigm of git branches or PowerBI development pipelines?
Does it work with metrics too? For example: you have a team that will develop dashboards in Power BI, but each of them is using a specific branch and they will make different pages in Power BI, each creating their specific metrics.
Q: @adam - I tried using this, we have an issue with sync, the error message says datasetdefinition: required artifact missing. When I checked the required fes needed in the microsoft blog, the name says as definition.pbidataset but when I save it as a .pbip, it stores the datset under semanticModel with just “definition” folder name. Does this naming convention cause an issue while trying sync and throw an error saying required dataset artifact missing or I’m missing something all together. Please answer this question, it would save ton of time and effort.
He also did a RU-vid video: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-VT2L1SXFq9U.html&pp=ygVXc2NvdHQgaGFuc2VsbWFuIE15IFVsdGltYXRlIFBvd2VyU2hlbGwgcHJvbXB0IHdpdGggT2ggTXkgUG9zaCBhbmQgdGhlIFdpbmRvd3MgVGVybWluYWwg
It is important to know the limitations of Git in Fabric, too. Like size of files etc. Also, Premium pipelines have own limitations. Yes, it is good that Fabric has got those features but it is not enterprise-ready at the moment given the limitations.
Thanks for sharing Adam! this is exactly how I was working and it's great to see you guys doing it to compare best practices for repo integration. I guess we just need to wait for an automatic way of pulling the changes to the workspace and update the App with Rest API and we could finally build an amazing version controlled by environment CICD. I can't stop thinking that deployment pipelines will be a different approach but not necessary if we keep this amazing practices keeping developers working with repos and DataOps with Fabric.
Q: I'm confused because we can use just prod and Dev workspace as it is and for version control we can use OneDrive. Personally I think this is little bit lengthy process. Please correct me if I'm wrong. BTW @GuyInACube, I'm big fan.
This is great!! Should organizations start using this at a global level while this is still in preview or should they wait for a general availability release?
Why does a merge conflict occur if main branch and dev branch create a new report page (which have nothing in common and different names). As soon as I rebase to combine both i get a merge conflict. That does not make any sense to me.
It would be nice to have REST API that allow to publish .pbip the same way as .pbix. On our project we have fully automated deployments from git repository and without REST API still need to have a pbix copy of report
How does the difference looks like between two commits? is it properly readable? Till Date I am using Sharepoint Check in & Check out method for version control of a pbix.
Would be interesting to understand how would GIT work if you have for example 5 different reports connected to a single semantic model where all artifacts are within a same workspace and would that create any problem while doing commits / pulls.
It would not be any problem, since each report would be saved as a separate pbip project and thus separate folder. Ideally, the semantic model would also be saved as a separate pbip so that you can more easily apply the golden dataset rule. So in the Git repo you would have 6 folders, one for the dataset and one for each of the 5 reports that go into the workspace.
@adam what if i just want to upload the report in the repo in dev branch and raise a PR instead of using got commands on console. Is that feasible. I think it is feasible but what file we need to upload or replace the pbip or everything.
it's a total of 5 commands.. git pull, git checkout -b "XXX", git add. , git commit -m "XXX", git push Write it down and repeat, it's pretty much a standard.
Thanks. I love using the Git integration. Source control in VS Code makes it a BIT easier, but still a bit heavy for a non business user. A small, well meant challenge: Try do a few videos leaving out the word “Perspective”
