/work
Ephemeral Workspace Deployment Architecture
[ overview ]
Summary
Redesigned the Power BI deployment architecture to eliminate static DEV/TEST environments and enable Git-driven, ephemeral workspaces.
Context
Scaling Power BI delivery required removing manual promotion steps, simplifying environment topology, and enabling production changes without impacting end users. The platform needed to support up to 15 concurrent workspaces.
Solution
Introduced a production-only workspace model with branch-scoped ephemeral environments, fully automated via GitHub Actions.
Outcome
Simplified deployments supporting up to 15 concurrent ephemeral workspaces, reduced operational overhead, and zero-downtime production changes.
[ tools & formats ]
[ implementation details ]
Workspace topology
The Power BI environment was redesigned around a single long-lived production workspace, with all development and testing happening in short-lived, isolated environments.
This removed the need for permanent DEV and TEST workspaces while significantly simplifying environment management.
- One long-lived production workspace
- Ephemeral workspaces created per Git branch
- No permanent DEV or TEST workspaces, supporting up to 15 concurrent ephemeral environments
Branch-driven environment provisioning
Environment creation is fully driven by Git workflows and closely integrated with the ticketing system.
Each change starts with a branch, and each branch gets its own isolated workspace.
- A new Git branch is created directly from the ticketing system
- Branch creation automatically provisions a corresponding ephemeral workspace
- CI workflows deploy semantic models and reports into the branch workspace
Production simulation for testing
To ensure realistic testing without duplicating entire environments, production behavior is simulated inside ephemeral workspaces.
This allows developers to validate changes against production-like report structures while keeping data access controlled.
- All reports bound to the production dataset are mass-copied
- Reports are automatically rebound to the ephemeral semantic model
- Test data exposure is controlled using RLS roles
Deployment mechanics
Native Power BI deployment pipelines were intentionally excluded in favor of a fully GitHub Actions–based approach.
This provides better transparency, versioning, and alignment with the engineering platform.
- Native Power BI deployment pipelines are not used
- All deployments executed via GitHub Actions
- Dataset ownership enforced via service principals
- Centralized connectivity via shareable cloud connections
- No manual changes allowed in production workspaces
Automated lifecycle management
Ephemeral environments are treated as disposable infrastructure and managed automatically.
Once a change is merged and no longer needed, the environment is removed without manual intervention.
- GitHub Actions monitor merged branches
- After a defined retention period, the corresponding workspace is deleted
- Associated datasets and reports are removed together with the workspace
Production workspace migration
The architectural redesign required changes to existing production workspaces.
These changes were executed programmatically to avoid any disruption for business users.
- Bulk export and import of reports and datasets
- Automated rebinding of reports to newly deployed semantic models
- Permissions and refresh behavior preserved
- No user-visible impact for business users
What this enables
By redesigning the workspace and deployment architecture, the platform gained a simpler and more scalable operating model.
- Simplified and scalable Power BI environment topology
- Fully Git-driven workspace and deployment lifecycle
- Safe, isolated testing without permanent non-production environments
- Zero-downtime production changes
- Reduced operational and governance complexity