/work
CI/CD for Power BI
[ overview ]
Summary
Automated deployments, regression tests, and approvals for Tabular models and Power BI reports.
Context
Power BI CI/CD pipelines originally implemented in Azure DevOps were migrated to GitHub Actions to align with a GitHub-first engineering platform. The platform handles ~30 deployments per month.
Solution
Designed and rebuilt the CI/CD architecture from scratch, introducing PR-level validation, regression checks, approval gates, and automated deployments for both semantic models and reports.
Outcome
~30 automated deployments per month with readable error traces, standardized release workflows, and reduced risk across environments.
[ tools & formats ]
[ implementation details ]
Repository structure
The CI/CD platform is implemented using two dedicated monorepositories:
- One repository for Power BI semantic (Tabular) models
- One repository for Power BI reports
Both repositories follow the same engineering standards, including:
- Structured README documentation describing delivery and deployment flows
- Standard repository configuration (`.gitignore`, `.gitattributes`)
- CI status badges
- Pull request templates with explicit intent and validation checklists
This ensures consistent contribution practices and predictable delivery across analytics assets.
Semantic models: PR validation & deployment
Changes to semantic models are governed by a required pull request validation workflow.
The PR validation is dynamic and executes checks based on the actual scope of changes introduced in the pull request.
Implemented validations include:
- Validation of a controlled deployment mapping configuration defining which datasets are eligible for publishing
- Tabular Editor Best Practice Analyzer (with warning-level and fail-level rules)
- Environment safety checks, including source database name, server name, and warehouse name validation
- Detection of forbidden artifacts such as embedded credentials, secrets, or local file system references
- Validation of the CI workflows themselves to prevent broken automation from being merged
Only pull requests that pass all required checks are eligible for merge. Merges are restricted to squash merges and are automatically performed once all checks succeed.
Semantic models: production deployment
After a successful merge to the main branch, the pipeline automatically:
- Publishes the semantic model to a higher-environment workspace
- Transfers dataset ownership to a managed service identity
- Attaches a shareable cloud connection
- Executes recalculation only (no automatic data refresh)
No manual changes are allowed in higher environments.
Automatic refresh is intentionally not triggered as part of the deployment process, allowing explicit control over refresh timing while multiple safe automation strategies are being evaluated.
Reports: validation & publishing
CI/CD for reports follows a deliberately simpler validation model.
Pull request validation for reports focuses on ensuring correct dataset binding prior to publishing:
- Reports must be bound to the approved semantic model
- Bindings to development or test datasets are explicitly rejected
Once validation passes, reports are published without additional transformation or post-deployment actions.
This approach ensures reports always point to approved datasets while keeping report delivery lightweight and predictable.
What this enables
- ~30 automated deployments per month with readable error traces
- Deterministic and auditable releases for both semantic models and reports
- Strong PR-level governance without slowing down delivery
- Clear separation of responsibilities between validation, approval, and deployment
- Secure higher-environment deployments with zero manual intervention post-merge
- A scalable foundation for extending CI/CD across additional Power BI assets