I spent a couple of weeks researching the topic of version control for Power BI. At the end of this article, I'll share a few links so that you can do the same and decide what's best for you and your team.
The manual version control/backup strategy that most BI developers are doing is taking copies of the report in case your computer crashes or you decide your concept is not working and you would rather roll back the changes to a specific version. Sometimes all you can do is step back in time.
A shared library on Sharepoint/OneDrive is an ideal place to store these files.
Simple Azure Devops setup
The next step in complexity is to set-up Azure Devops and connect a respository to your workspace.
After doing so, you publish the reports from desktop the same way but you will also commit the changes with a short note to the repository. In Azure Devops you will be able to track changes and download (clone) an earlier version. Use the project pbip file format for power bi as the newer pbir format has serious limitations. It is strongly recommended to set this up for the production and the development workspaces.
For Fabric it is imperative to use version control as most of the development is done in the cloud and clicking delete on a pipeline by mistake can lose it forever; also since taking over Fabric items is not working properly, version control is a good way to not lose access to an item if your colleague goes on vacation.
Feature branch
Subscribe to the Fabric Dojo for tutorials. Let's say that you start working on a new feature on a report but a week later the project is postponed, the scope is reduced to fixing a bug in the existing version.
You would need to restore specifically the production version - including the SQL views before you started working on the new feature(s). This is one of the scenario that the feature branch solves. It leaves the main branch intact until you test and validate the new iteration. A feature branch is a copy of your main branch that you will work on until you "finish" the feature. It also helps collaboration as you don't need to ask which one is the latest version or what were the latest changes, you can just see the file history and clone a version or pull the latest version. This terminology is a bit new to me.
Git basics
You can use Azure Devops and VSCode and use the UI to stage, commit and push your changes to the repo/ workspace. I don't think it is prudent to skimp on learning the basics of git. When (and not if) you are going to have an error message, it's much easier to fix if you are aware of where you are in the workflow, you can debug your problem better by knowing that your git commit - m "Message" produced an error compared to saying that you clicked on a button.
I did 3 courses on Datacamp, Beginner Git, Foundations of Git and Intermediate Git. Interestingly they seemed like they are just copies of each other with some minor changes just like a feature branch; there were significant overlap between them but each contained something that were distinct.
Deployment pipelines
The dep. pipelines are confirming my view that usually there are 3 workspaces, dev, test and prod.
You publish your changes to dev to see the report in a cloud environment, preferably someone reviews the changes, either a colleague or the business owner, project manager perhaps, then the changes are deployed to a test workspace and app where optionally there is a larger group of users testing.
You can't just skip the development app as new features are frequently breaking former improvements and deploying bugs would disturb your test group. This power bi premium feature is very useful for creating rules such as changing the data sources while deploying from test to production for example, the same thing would be rather complex in Azure Devops.
Feature branch considerations
If you are using a feature branch then you should create a workspace to publish your feature version to as a report in desktop might look different after publishing, also in editing mode some visual elements for example header icons are not visible.
You have 4 workspaces now or if you have multiple developers working on the same project, then even more. You have to give access to this feature app to the customer, business owner etc to approve your changes. Now the customer have to keep track of your feature branch app link, your colleague's other feature branch app link, the dev, test and production app links as well. Personally, I don't share links and ask users to find them via powerbi.com under my apps.
If you don't want to use a feature workspace then it could happen that the steps for version control takes twice as much time as change you make. For example if you have to fix a typo, a data label or a simple measure, that takes a ... short amount of time, but you still would have to stage the change, commit it, pull and push to the feature branch then create a pull request to merge it to the development branch/ workspace. The next time you'd see a minor problem, you would just ignore it as you would not want to bother with the version control steps.
A possible middle ground / conclusion
Option A: Feature Branch with Workspaces
If you use a feature branch then you can minimize the nr of merges to the main branch by testing the report from the feature branch, you would only use the usual test app if there is an active test group. Once your feature is approved and no last-minute changes are expected, then you would merge the feature branch to the main/dev by creating a pull request the move the changes to test and prod. Moving to test would be a good test for moving the changes for the datasources to decrease the time it takes deployment to production.
Option B:
You can use version control to track your changes in a different repository that is not connected to your workspaces. You can keep using the publish button from the desktop and use a simple Azure Devops setup to commit your changes to a repository connected to the workspace via the source control interface. Development with Power BI is different compared to software development as you have to frequently publish to get feedback or see the report in a cloud environment. Development is more flexible, allowing easier changes. However, finishing a feature does not always mean it will be accepted without further requests. While using version control is a basic requirement for every development team, you have to find a way to reduce its possible overhead on development time.
You should still keep the manual backups on OneDrive. Both options would keep using deployment pipelines to move changes between dev, test and prod.
Useful links:
https://www.skool.com/fabricdojo
https://amalbenrebai.substack.com/p/fabric-git-integration-with-power
https://app.datacamp.com/learn/courses/intermediate-git