Start Coding: A Modern Power BI Workflow with TMDL and VS Code
- Jihwan Kim
- 3 hours ago
- 5 min read
In this writing, I’d like to share how I am evolving my Power BI development process. For years, building semantic models has been a UI-driven craft, a series of clicks and drags within the familiar confines of Power BI Desktop. But the game is changing. With the introduction of the Tabular Model Definition Language (TMDL) view, I am witnessing a fundamental shift from a manual art form to an engineered discipline. It’s time to stop just clicking and start coding.
This isn't about replacing Power BI Desktop. It's about augmenting it with the power, precision, and collaboration tools that have been standard in software engineering for decades. By embracing a local development workflow centered on TMDL, Visual Studio Code, and Git, I can elevate my work, improve quality, and collaborate in ways that were previously impossible with just PBIX files.
The Chaos of the Shared PBIX File
Think about a common scenario in any enterprise BI team: multiple developers need to work on a single, critical semantic model. The traditional workflow is often a chaotic ballet of file sharing.
Developer-Jihwan adds a new set of sales measures and saves it as Sales Model_v2_JihwanEdits.pbix.
Meanwhile, Developer Alex is fixing a bug in the product dimension calculations in their own copy, Sales Model_v2_AlexFinal.pbix.
How do we merge these changes? The answer is a painful, manual, and error-prone process of opening both files and copy-pasting DAX, or worse, trying to replicate UI changes by memory. There is no reliable version history, no clear audit trail of who changed what, and no way to perform a "diff" to compare the two versions. This approach doesn't scale and introduces significant risk. It’s a craft, not a professional engineering process.
A New, Code-Centric Workflow
The solution lies in shifting my perspective: treat the semantic model as what it is—code. With Power BI Projects (PBIP) and the TMDL view, I finally have the tools to do this effectively.
1. The Foundation: From PBIX to PBIP
The first step is to move away from the monolithic PBIX file. When I save my work as a Power BI Project (.pbip), Power BI Desktop unpacks the model definition into a folder structure containing human-readable TMDL files. Suddenly, my model is no longer a black box. Every table, column, measure, and relationship are defined in a text file that I can open, read, and, most importantly, place under source control.
2. Setting Up my Local Environment
My new toolkit is simple and powerful:
Power BI Desktop: Ensure I have the Power BI Project (.pbip) save option preview feature & TMDL View preview feature enabled (File > Options and settings > Options > Preview features).
Visual Studio Code: A lightweight and versatile code editor.
Git: The industry standard for version control.
The setup is straightforward:
1 Open your model in Power BI Desktop.
2 Use File > Save as and choose the "Power BI project files (*.pbip)" type.
3 In your terminal or Git client, navigate to the newly created project folder and initialize a Git repository (git init). You now have a baseline for your model that you can track.
Navigate to my Project Directory: First, ensure my terminal's current path is your Power BI Project folder—the one containing my .pbip file and the dataset and report subfolders.
Initialize Git: Run the git init command. This command creates a new, hidden subfolder named .git that contains all the necessary repository files—a Git repository skeleton.
I can see a confirmation message like below:
(Crucial) Create a .gitignore file: This is a step that makes me like the pro Power BI developer. Power BI Desktop creates temporary cache and user-specific files (like cache.abf) that should never be committed to source control. A .gitignore file tells Git to ignore these files.
Create a new file in my root project folder named .gitignore (or, check if it is already created) and add the following content. And then Save the file.
This ensures only my essential model and report definition files are tracked.
Stage the changes, and then I can make my first commit.
3. The Core Workflow: A Hybrid Approach
The beauty of this new workflow is its flexibility. I can seamlessly move between the familiar Power BI UI and a powerful code editor like VS Code.
Editing in Power BI Desktop: The TMDL view inside Desktop is my new command center for scripting changes. Let's say I want to change the display folder for several measures. Instead of clicking on each one, I can drag the measures into the TMDL view, script the changes, and even preview a "diff" of my modifications before applying them. This alone is a huge time-saver.
Editing in VS Code: This is where you unlock true developer productivity. Open the entire PBIP folder in VS Code. Imagine I need to rename all your tables to remove a _dim_ prefix. Instead of dozens of clicks, I can use the find-and-replace feature with a regular expression to make the change across the entire model in seconds. This is the power of treating my
model as code. In this case, be noted that visualizations might be broken because the name of the columns are changed, for instance, from _dim_calendar[Year] to Dimension_calendar[Year], you can get the point that changing something in Power BI becomes efficient and effective.
Source Control with Git: Every change I make, whether in Desktop or VS Code, can be tracked with Git. After refactoring my table names, running git diff will show me exactly which lines in which TMDL files were changed. The diffs are meaningful because TMDL is human-readable. I can then commit these changes with a clear message, creating an immutable history of my model's evolution. This is the foundation of BI-as-Code.
As a side note, I use Git Graph extension in VS Code.
Summary
Adopting this workflow is more than a technical change; it's a mindset shift. We are moving beyond the role of "report builders" and becoming true analytics engineers. For any serious Power BI professional today, proficiency in Git is no longer optional—it is a core competency.
My team has begun standardizing on this local development workflow for our most important semantic models. The impact on quality and governance has been immediate. The ability for one developer to submit a change as a pull request and have another developer review the exact TMDL modifications before merging is a game-changer. It enforces consistency and catches errors before they ever reach a user. This structured, code-centric approach is the key to building robust, scalable, and maintainable BI solutions in an enterprise environment.
I hope this helps having fun with building more robust and scalable Power BI solutions. The move to a code-centric workflow with TMDL, VS Code, and Git is one of the most significant advancements in the Power BI ecosystem. It empowers to apply proven software engineering principles to my work, transforming our development process from a manual craft into a professional discipline.
I encourage you to enable the TMDL preview feature, save one of your existing reports as a Power BI Project, and open it in VS Code. Try making a small change and see the difference for yourself.
References
Comments