Dyota's blog

PBIP, PowerShell, and git

PBIP, PowerShell and git

Intro

These are two things that I use daily. The main two benefits for today are:

  1. Rip out all code as text files
    • Ctrl + F search through all code
    • View code (e.g. four different measures) side by side
  2. Automatically arranging report pages
    • Show, hide, reorder
  3. Version control and branched development
    • Work on isolated features, switch contexts, test independently, merge features in isolation

Background

PBIP

PBIP (Power BI Project) is one of the save formats. Instead of a single .pbix file, it breaks it up into a few folders with a lot of files in it.

Examples:

The critical thing to know about the .pbip is "reconstitutable". This means that the files can be edited and then opened again in Power BI. Editing can either be done by hand, or by a computer script.

PBIX is a zip folder. .pbix can be renamed to .zip, and have all the files extracted, etc. I've found that .pbix is not reconstitutable. It doesn't work if you crack open a .pbix file, edit the contents, re-zip and rename to .pbix, and try to open it in Power BI.

PowerShell

PowerShell is a general-purpose programming language. Every Windows installation has the PowerShell runtime (at least Windows PowerShell 5.1).

The critical thing to know about PowerShell is that it is good in these ways:

git

Git is version control software. It allows you to have different version of the same file, in the same location.

Because the PBIP format has all of its guts exposed, they can be committed to a git repo and all of the changes are made clear.

This also allow branching and the merging/integrating of very specific parts of code.

Terminology:

Together

By working in the PBIP format, I can use PowerShell scripts to programmatically manipulate Power BI files.

Case studies

Rip out all code

Arranging report pages

I have a semantic data model with several reports coming off of it. Some of the reports have the same pages in them. They should all be kept in sync.

The setup is like this: there is a folder, where all of the project folders live. One of them is the "master", i.e. the .pbip folder with the semantic data model in it. The rest of them are reports.

The master folder has all of the pages in it (i.e. the child reports have pages are a subset of the master). Each child report has a file called pages.json. This defines which of the pages are shown, and what order they should be in

Each report PBIP has a file in i

Steps

  1. Have one master report with all of the changes in it

  2. For each child report, have a file called pages.json, which defines which of the pages are shown, and what order they should be in

Version control

Guardian has gone live, and when I took over as the main Power BI developer for them, they had several new features or build changes.

I carried on for several of these but introduced breaking changes into production. So, I developed a way of working with git branching.

Steps

  1. Make a new branch, give it a one=word name
  2. PowerShell script renames the .pbip file with the branch name appended
  3. Work on the feature
  4. Publish it to the same workspace (now the Power BI file has a different name)
  5. When client is happy, merge the changes into master (carefully) and publish