Microsoft Fabric GitHub / DevOps: Power BI grows up

Microsoft Fabric Git - with Azure DevOps Logo

This may mean little to a non-developer, but to anyone interested in the future of their data management, in Microsoft Fabric, it matters a great deal.  Microsoft have launched for Power BI and Microsoft Fabric Git integration, which makes a huge difference to how Power BI and Fabric are used by professional development teams and “DevOps” teams.  

I’ll make the case here that this is Power BI growing up. We will aim for a non-technical explanation.

Executive Overview:

Now that Power BI is part of the new Microsoft Fabric product suite, there are more refined controls for the process of report development, approval and updates.  This means that report changes can be managed in a controlled way, with approvals, and tested separately from the live reports.  Like a professional development team this means that your critical business reports are fully tested each time alterations are made, and before they are presented to decision makers.

When you combine these controls with the improved controls over who accesses what data in Fabric OneLake, you now have a fully mature system of access controls on your organizational intelligence. These controls increase your confidence in the quality your reports, ensure everyone has the correct (latest) version of each report, and ensures that your critical business data cannot leak to the wrong people.

The Detail:

What is “Git”?

“GIT”, GitHub, or GitLab, describes a system where you don’t instantly make changes to a live file or programme, which can easily be broken by the wrong change.  Instead, mature development teams, take a replica of the live environment called a “branch”.  They make their changes to this branch in a development environment which is completely separate, and test them there until, in theory, all bugs are removed.

Then they push those changes “up” to a test environment, where another developer has to review them.  They may also merge their changes with other developers’ changes, test again, and only then push these changes up to the live environment when the combination of multiple people’s work is fully tested.

Git also retains all the previous versions of a file or programme, so that if you need to revert to a previous version, it is relatively easy.

This is how professional development teams work.

In fact the initial set up in Fabric doesn’t use GitHub itself, instead it uses “Azure DevOps”.  While built into the Azure platform, is a very close comparison to GitHub.  For ease we can call it “Git”.

Schematic of the Azure DevOps process:

From Git to “Continuous Deployment”

There’s one further step in this process, and this is when a team builds automated tests to run on every product, when each deployment or “push” happens.  This ensures that code is never pushed to the next environment until it has passed these critical tests – and people don’t have to test it all manually every time.  It takes a development team towards a thing called “CI/CD”, (Continuous integration and continuous deployment), which usually means they are much more efficient at rolling out new changes on a regular basis.  Rather than the old system of quarterly product updates, teams using CI/CD may be able to safely put changes live on a weekly or even daily basis.  It is a great improvement in developer productivity, and it all rests on the initial use of Git.

The “Wild West” of Power BI

Contrast this with how people have used Power BI and similar “Office” products like Excel and Word since their inception.

  • Anyone can take a copy of a report or a file, change it, use and distribute it.
  • There may be many similar copies of the same document in circulation.
  • You and I might make a report with the same data, but showing different answers because of how we’ve built it.
  • There’s no official version of any report, either yours or mine might be emailed to someone.
  • If I modify a report and it breaks, there’s no official process for picking that up.  We hope someone notices.
  • If I want to go back to a previous version, I would have to try to find it, and hope that somewhere I had the correct version saved.

This effectively describes the “Wild West” process which reflects a normal organization’s Power BI reporting.

Microsoft Fabric Git & DevOps

What Microsoft have launched with Microsoft Fabric is the ability to use a full GIT deployment pipeline on all your reports, Power BI, and most other assets within Fabric.  While you are not forced to use Git, wherever organizations are used to using Git for their development, and where they want to ensure that reports are not simply broken by the latest set of changes change, it makes sense to adopt this way of working.

Changing how Power BI works

To achieve this there have been quite a few changes to Power BI, and the way it sits within Fabric, to make this possible.  One is that the file format itself had to be changed.  The “.pbix” file we’re all used to in Power BI there’s been added another type, the “.pbip” which stands for a “Power BI Project”.

These files which make up a Power BI report are now text-based, so you and I could open and read them in Notepad or a similar text editor application.  And this in turn allows the Git programme to show the changes, word by word and line by line between one version and the next.  This is a key part of how Git works: other developers can easily see what has changed between versions of the same code or Power BI report.

As a Business Stakeholder

If you’re a business stakeholder, you may not worry unduly about the details of Git, but it is worth understanding this fundamental change to the way Power BI can be used.  Being part of Fabric, and with GitHub deployed, there is now a controllable flow to report development, a system for testing and approval of reports, and only one official “live” version of each.

When you add this to the controls over the data based around OneLake, this becomes formidable.  All your data is now kept in one place, the OneLake, and it can be configured who is allowed to access data row by row and table by table.  For example, perhaps salary data is only available to HR, and certain financial information only available to the CFO and the board.

Controlling your report code AND data

Between the GitHub controls over report code, and the OneLake controls over your data, you now have a fully managed and controllable system for ensuring that your reports don’t break, your data doesn’t leak, and testing and approvals happen as you need.

There is nothing to stop you carrying on doing this the old way – you can still keep the Wild West and manage every report as though it was a Word document.

Power BI Grows Up

Mature organizations will welcome the step changes that Microsoft Fabric Git integration brings to Power BI and their reporting. The opportunity to increase trust in our reporting, safeguard customer and organizational data, and ensure people are accessing the correct versions of data and reports, are all critical for an organization.

With these changes Fabric has given us the opportunity to move towards a grown-up and well controlled system for protecting our reports and our critical organizational data.

How to get started with Microsoft Fabric Git & DevOps

For teams getting started with Microsoft Fabric, Git or Azure DevOps, Comset consultants will be able to advise on the right way forward for you. Of course there is a mass of information out there about how to use Git tools as part of a development team, but the concept is relatively new to Power BI and reporting, so its important to bring the skills of experienced DevOps teams to bear when setting up the reporting estate properly.

As ever please drop a message to your friendly Comset consultant who will be delighted to help you get started in the right direction.