From Version Chaos to CI/CD: Power BI Version Control with GitHub

How Power BI Project Files Changed the Game – And Why CI/CD is the Next Logical Step

The Old Way: A Naming Nightmare

A long time ago, version control in Power BI looked like this—at least, this was my way of tracking changes in a project:

Before Git: Project name & Date & version number - lots of them😅

I’m confident I don’t need to explain the issues with this “system.”

I still remember a meeting where my team burst into laughter as I shared my screen—my latest version was named _v147 _v15. I felt the same way, but at the time, better options simply weren’t available or required so many approvals that they were practically impossible to implement.

I also remember the first time I opened a ServiceNow ticket at a previous company, requesting approval to use the Power BI DevOps extension or another third-party tool for version control. 1.5 years later, when I left the company, the ticket was still open, bouncing back and forth between InfoSec and other teams, waiting for sign-off.

And so, time passed. New files named _v123, _v146_final, and _v147_final_corrected kept appearing…

Until suddenly, Power BI Project Files were announced as a preview feature. And I got very excited. 😱🥳

Say goodbye to files like “Project_v145_final_corrected.pbix”

If you’re unfamiliar with PBIB, its main goal is simple:

Instead of saving your work as a single .pbix file, you can save your Power BI project as a folder structure containing multiple (JSON) files.

The folder structure introduced with PBIB. (Source: MS)

But this wasn’t the only game-changer.

The long awaited TMDL (Tabular Model Definition Language) was announced as well.

TMDL described by MS.

With TMDL, we’re no longer stuck with a monolithic JSON file. Instead of treating the model as a black box, we can now break it into structured, readable code.

✅ Measures, relationships, and metadata are now stored in individual files, making collaboration easier.
✅ You can review, edit, and track changes at a more granular level.
✅ More advanced CI/CD scenarios become possible, such as automatically enforcing formatting, best practices, or data validation in Power BI models.

This is more than just version control—this is a step towards treating Power BI models like true, managed code.

Before & After: How Version Control Transforms Power BI

Before PBIP, comparing changes meant manually opening multiple older versions - painful and time-consuming.

But with PBIP (+ TMDL)?

No more opening old files manually—just use VS Code (or any code editor) to instantly track and review differences!

Need to compare changes?🧐 Here is how it looks in VS Code!

This alone is a huge step forward. But here’s the catch: once you and your team get comfortable with this approach, a new challenge appears.

I’ve already shared the beginning of our journey with version control in Part 1 and Part 2. If you’re looking for a step-by-step guide on setting up version control with Azure DevOps, check out Part 3.

Otherwise, let’s shift our focus to what comes next—because version control is just the beginning.

So… what’s next? 🌱➡️🌿➡️🌳

Once your team starts using this approach, you’ll run into new questions like:

1️⃣ How do we maintain consistency across multiple projects?

Wouldn’t it be nice to have a Measure folder to organize all measures across projects by default?

2️⃣ How do we prevent suboptimal practices from reaching production?

Before pushing to PROD, you probably want to review why there’s a bi-directional relationship in a project.

3️⃣ How do we standardize work across developers with different backgrounds?

It doesn’t matter if it’s you, a trainee, a former Tableau developer working on Power BI project, or someone who’s been using DAX from the beginning—you and your team will want all DAX formatted consistently by default.

And this is where CI/CD (Continuous Integration & Continuous Deployment) begins.

Automation: The Missing Piece in Power BI CI/CD

At this stage, it’s not just about version control anymore.

If you’re “only” using version control—congratulations, you’ve already made a huge leap forward! 👑

But now, you have two clear paths ahead if you want to automate and set up a CI/CD pipeline:

1️⃣ GitHub & GitHub Actions
2️⃣ Azure DevOps & Pipelines

Right now, my team is in the early stages of adopting GitHub Actions Workflows (GA).

And the possibilities are endless.

Everything you can do with Tabular Editor, PBI Inspector, DAX Studio, or any tool with a Command Line Interface (CLI)—you can automate with GitHub Actions.

Or, if you want to write scripts in Python with SemPy or implement data quality checks, you can do that too.

“That’s nice, but I already have enough problems to deal with…”

For those wondering, "Is this overkill?"—it doesn’t have to be. Even basic CI/CD can deliver major benefits.

Here’s an example: 🛠️🔎🚨Automating Best Practice Analyzer🔬📊🤖

Before merging a Power BI model to production, a GitHub Actions workflow can:
✅ Run Tabular Editor’s Best Practice Analyzer
✅ Detect hardcoded filters, unused columns, and inefficient measures
✅ Prevent bad practices from ever making it to PROD

This isn't just fancy automation—it’s a way to ensure consistency, improve performance, and eliminate costly mistakes.

Here’s a workflow that flags a measure using the “/” operator instead of the recommended DIVIDE function.

This GitHub Actions workflow automatically downloads, installs, and runs Tabular Editor 2.x. The process halts when it detects an issue. 🚨 Disclaimer: The severity of this example is intentionally exaggerated. In reality, using / should only trigger a warning, not a full stop.

Here (will) come the cavalry!

This post was just a teaser—I wanted to plant the seed. 🌱

In my next blog post, I’ll dive into the technical side of this journey:
✅ How to create a GitHub Actions workflow
✅ How to apply the Best Practice Analyzer to your Power BI file

Stay tuned! 🚀