i

Description

Falaise de roches sédimentaires empilées en couches successives, chaque strate conservant une période.

Source

DimiTalen · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Version Control and Industrialization of Reports

This topic assesses how a BI product is stored, reviewed, merged, deployed, and restored: Power BI Project (PBIP) projects with TMDL (model) and PBIR (report) definitions, Git or TFVC…

In brief

This topic assesses how a BI product is stored, reviewed, merged, deployed, and restored: Power BI Project (PBIP) projects with TMDL (model) and PBIR (report) definitions, Git or TFVC, change review, dev/test/prod environments, deployment pipelines, parameter rules, XMLA/TMDL scripts, rollback. For source control principles, see Source Control for Data: SQL and Power BI.

On this page

1. 1. Why this topic
2. 2. What this topic measures
3. 3. The 5 levels
4. 4. Milestones by level
5. 5. Detailed reading by level
   1. 🟢 Level 1 — Shared file
   2. 🟢 Level 2 — File repository
   3. 🟡 Level 3 — Text project
   4. 🟡 Level 4 — Pipeline
   5. 🔴 Level 5 — Continuous
6. 6. Partial achievement and rating
7. 7. Moving to the next level
8. 8. See also

Level: 🟢→🔴 · Theme code: IND

1. Why this topic#

A .pbix is a compressed binary: impossible to compare, merge, or review line by line. Two people editing the same .pbix step on each other, and one loses their work. The PBIP format (first in preview, now stabilized; to be verified depending on the feature) breaks the product into text files: *.SemanticModel/definition/*.tmdl (tables, measures, relationships, roles, cultures) and *.Report/definition/ (pages, visuals in PBIR JSON format). Text can be versioned, diffed, reviewed, merged. Without this, there is no code review, no history, no reproducible deployment.

2. What this topic measures#

• Axis: from shared file to continuous delivery pipeline with rollback.
• Key indicators: share of BI artifacts versioned in text format; deployment frequency; rollback lead time; share of reviewed changes; deployment failure rate.
• Units: %, deployments/month, minutes.

3. The 5 levels#

4. Milestones by level#

5. Detailed reading by level#

🟢 Level 1 — Shared file#

• Signs: Report_v3_final_OK.pbix, publishing from the author's machine, no idea what changed.
• Difficulty: 1/5 · Effort: 1/5.

🟢 Level 2 — File repository#

• Signs: .pbix files are in Git (or TFVC) with history; the repo grows (binary not delta-compressible), diff is impossible.
• Benefit: traceability, rollback to a version.
• Limit: no in-depth review, no merge.
• Difficulty: 2/5 · Effort: 2/5.

🟡 Level 3 — Text project#

Typical PBIP structure:

Rapport Ventes.pbip
Rapport Ventes.SemanticModel/
    definition/
        model.tmdl
        tables/FACT_VISITE.tmdl
        relationships.tmdl
        roles/Perimetre.tmdl
        cultures/en-US.tmdl
Rapport Ventes.Report/
    definition/
        pages/pages.json
        pages/<id>/visuals/<id>/visual.json

• Signs: a measure diff is read like code; two developers work on two tables; review is done on TMDL. TMDL has strict formatting rules (indentation, only one key column per table): a syntax validator before opening prevents project corruption.
• Benefit: parallelism, review, fine-grained history.
• Limit: merging report JSON files (PBIR) is still more delicate; visual identifiers are GUIDs.
• Difficulty: 3/5 · Effort: 3/5.

🟡 Level 4 — Pipeline#

• Signs: three workspaces (or three capacities); a deployment pipeline from the Power BI service, or a CI pipeline that publishes through APIs/command-line tools (Tabular Editor CLI, fabric-cicd, REST API — tools to verify by version). Parameters change by environment via rules, not manually.
• Benefit: reproducibility.
• Limit: not all objects deploy the same way (some sources, gateways, rights still require configuration); possible drift between environments.
• Difficulty: 4/5 · Effort: 4/5.

# Pipeline outline (logical steps, tool-independent)
stages:
  - validate:   # TMDL syntax, BPA, measure tests on the test model
  - deploy_test: # publish to the Test workspace with parameter rules
  - smoke_test:  # reference DAX queries, refresh
  - approve:     # human validation (business)
  - deploy_prod

🔴 Level 5 — Continuous#

• Signs: validated merge → automatic deployment to Test → prod promotion after tests and approval; rollback rehearsed; generated release notes.
• Benefit: deliver often, small, safely (see CI/CD: Continuous Integration and Continuous Delivery and CI/CD for data: foundations, datamarts, pipelines, and reports).
• Limit: a model change (schema) is not reversible like a report change (e.g., column deletion, lineage loss); rollback requires an upward-compatibility strategy.
• Difficulty: 5/5 · Effort: 5/5.

6. Partial achievement and rating#

Common rule. “A partial 5”: automatic deployment exists for the model, but not for reports (BI-IND-5.1 = 0.5); rollback never rehearsed (5.2 = 0); compatibility between kits verified manually (5.3 = 0.5); release notes written manually (5.4 = 0.5).

7. Moving to the next level#

Possible means (optional):

Pitfalls:

• False positive: “everything is in Git” but deployment still goes through manual publishing from Desktop.
• Goodhart: counting deployments encourages low-value micro-deployments; also measure failure rate and rollback lead time.
• Renaming a published object breaks connected reports: model delivery is a contract (MOD, DAX).
• Overwriting a colleague's work: without readable merge, last save wins.

8. See also#

• Related topics: TST · MOD · GOV · OPS
• Other matrices: DL — Version Control and Branches · DL — Deployment and Operations · PD — Lead Time and DataOps
• Content: Git In Depth · TFVC In Depth · Source Control for Data: SQL and Power BI · CI/CD · Azure DevOps Server (ex-TFS) in Depth

✻ Written by Claude Sonnet 5.5