Selected Work

Case 03 / 04 · 2025

J&D Power BI CI/CD

CI/CD for a Power BI report — the .pbip project version-controlled, automatically quality-gated, and promoted dev → test → prod behind an approval. Software engineering discipline, applied to BI.

View the code

01 · The problem

Most Power BI lives as clickops: a .pbix binary passed around and edited live in a workspace, with no version history and no quality gate. A broken measure or a sloppy model reaches production before anyone notices — and there is no clean way to review, roll back, or reproduce a change.

I rebuilt the J&D sales report’s delivery the way software ships. The report is source-controlled as a .pbip project, every change is automatically validated against model and report best practices, and it is promoted through isolated environments behind a human approval — reviewable, reproducible, and safe to release.

02 · Architecture

Fig. 01 The validation gate. The report is authored as a .pbip project in Azure DevOps Git; a commit to dev runs the validation pipeline — Tabular Editor’s Best Practice Analyzer on the model, PBI Inspector on the report — and only a green run lets the change merge to main.
Fig. 02 The release rail. From main, Power BI Deployment Pipelines promote the report across isolated Development, Test, and Production workspaces — with a Release Manager approval gating the step into production.

03 · How it works

  1. Report as code

    Saved in the .pbip format, the report’s model and pages are plain-text files — so they branch, diff, and pull-request in Azure DevOps Git like any other code, instead of living as an opaque .pbix binary.

  2. Automated quality gates

    Every commit to dev runs a validation pipeline: Tabular Editor’s Best Practice Analyzer checks the model and measures, PBI Inspector checks the report pages. A pull request can’t merge to main until both gates are green.

  3. Promoted, not republished

    Once on main, Power BI Deployment Pipelines promote the same report through isolated Development, Test, and Production workspaces — so changes are tested in a production-like setting before anyone sees them live.

  4. A human before production

    The step into Production is gated by a Release Manager approval — deliberate oversight and compliance before a change goes live, not an automatic push.

04 · Proof

Power BI Overview page: revenue, orders, profit and return-rate KPIs, a revenue trend against target, orders by category, and the top subcategories by orders and return rate.
Fig. 03 The Overview page — headline KPIs, a revenue trend against target, and the top subcategories by orders and return rate. Hidden slicers and drill-through keep it clean while staying explorable.
Power BI Customer Details page: total customers and revenue-per-customer KPIs, orders by income and occupation, a top-100-customers table, and the top customer by revenue.
Fig. 04 The Customer Details page — switchable KPIs, top customers by segment, and a no-purchase cohort that surfaces re-engagement opportunities.

05 · Outcome

The result is a Power BI report you can trust like code: every change is versioned, automatically checked against model and report best practices, and promoted to production only after it passes validation and a person signs off — no more editing live in the workspace and hoping nothing breaks.

View the code Ask the assistant about this