environments
Overview
Using a multienvironment approach is a proven best practice in Azure and Microsoft Fabric adoption strategies. It enables development teams to deliver new features safely and efficiently while minimizing risks and disruptions to users.
This model supports continuous improvement, ensures compliance with quality standards, and fosters collaboration between developers, testers, and business stakeholders. By separating environments, teams can validate changes in isolation before promotion to production.
Microsoft recommends applying Continuous Delivery (CD) principles with automation and controls across a pipeline that targets multiple environments. This reduces the risk of deployment errors and improves development velocity. For detailed Microsoft guidance, see Use multiple environments for application lifecycle management.
Common Environment Tiers
A typical multienvironment setup includes:
| Environment | Description |
|---|---|
| Development | Where code and configurations are developed and unit tested. |
| Test | Used for automated or manual integration and functional testing. |
| Staging | Mirrors production as closely as possible for final validation. |
| UAT (User Acceptance Testing) | Used by end-users or business teams to validate business functionality. |
| Production | Live environment used by end users. |
Additional details: Environment strategies
Design Considerations
- Keep environments as identical as possible to prevent configuration drift.
- Automate deployments using Infrastructure as Code (IaC) tools like Bicep, Terraform, or the Fabric CLI.
- Implement automated checks and stage gates in CI/CD pipelines to block deployment to higher environments if tests fail.
- Use branch protection and pull request policies to enforce review processes.
- Leverage deployment strategies like Canary Releases or Blue-Green Deployments to minimize production impact.
- Segregate Service Principals for dev/test/prod to minimize lateral movement risks.
- Enable access control and auditing per environment using RBAC and Microsoft Entra ID governance features.
- Establish clear environment naming conventions and consistent tagging (e.g., env=dev, env=prod) to simplify automation and monitoring.
- Define environment-specific configuration variables and secrets using secure tools like Azure Key Vault or Fabric's item-level security.
- Use environment drift detection tools or IaC validation scripts to verify alignment between declared and actual state.
- Consider environment parity checks in your pipeline to compare environment setup and configuration.
Fabric-Specific Guidance
In Microsoft Fabric projects, environment transitions typically involve:
- Isolated Fabric Workspaces per environment.
- Different Fabric Capacities (e.g. test capacity vs. production capacity).
- Environment tagging on Fabric items (datasets, reports) for traceability.
- Separate GitHub environments or Azure DevOps pipelines for each stage.
- Separate OneLake file systems per environment, where applicable, to prevent data leakage or cross-environment contamination.
- Use Fabric APIs or Fabric CLI to automate provisioning and decommissioning of environment-specific resources.
- Align Fabric capacities with SLAs: use Premium capacity for production and shared/test capacity for non-prod.
- Assign environment-specific permissions using workspace roles and Entra ID groups with scoped access.
Consider implementing a central orchestration layer (e.g. GitHub Actions, Azure DevOps, or a Management Workspace) to coordinate deployment flows across environments.
Testing Platform Changes (Landing Zone)
To safely apply changes to the Fabric landing zone (e.g. Azure Policy, RBAC, or Entra ID configurations), use:
- Sandbox Subscriptions to test changes.
- A Canary environment that mimics production.
- GitOps or AzOps approaches to track and control changes via source control.
- Define rollback strategies per environment and validate them periodically via chaos engineering or failure simulations.
- Use feature flags to control rollout of critical platform features and to perform progressive delivery testing.
- Monitor environment-specific metrics and alerts using Fabric Monitoring and Azure Monitor for workload health.
Microsoft reference: Testing approaches for enterprise-scale