Deploying based on env specfic values

Question

when we have dev , prod environments , i understood that we use workspace to get seperate state and also to have env specific values, but we need to remember this switching to workspace,

how we can do this without switching to workspace, any other best way to achieve this?

Answer 1

Environment-specific behavior can be achieved without manually switching workspaces by externalizing configuration and using environment-aware deployment patterns.

Key options supported in the provided context:

1. Use variables for environment-specific values
   • Store environment-specific values (for example, connections, workspace identifiers, API endpoints, configuration settings) in a Variables Library instead of hardcoding them in definitions.
   • The same item definition (pipeline, notebook, job, etc.) can be deployed across Dev → Test → Prod, while each environment/workspace has its own variable values.
   • This avoids manual workspace switching for configuration changes; deployments read the correct values from the target environment’s variable library.
2. Use item definitions with CI/CD
   • Keep item definitions (state) in source control and promote them through environments using CI/CD.
   • The same definition is carried from source to target workspaces; environment-specific differences are handled via variables rather than separate manual workspace edits.
   • This enables automated promotion (Dev → Test → Prod) without relying on interactive workspace switching.
3. Use workspace-level environments (for Spark workloads)
   • In Fabric, a workspace admin can set a default environment at workspace level.
   • Notebooks and Spark job definitions that use “Workspace default” automatically inherit the environment’s compute and library configuration.
   • For cross-workspace reuse, an environment item can be attached from another workspace (subject to capacity and network compatibility), so the same environment definition can be reused without manually reconfiguring each workspace.
4. Use variables for cross-workspace references
   • When items reference other resources (for example, lakehouses, databases, workspace IDs), define those as variables.
   • On deployment to another workspace (Prod vs Dev), only the variable values change; the logic remains identical.

In practice, a recommended pattern is:

• Keep a single logical definition of automation/workloads in source control.
• Use CI/CD to deploy to Dev, Test, Prod workspaces.
• Use variable libraries (or equivalent configuration) per environment/workspace so that deployments automatically pick up the correct environment-specific values, minimizing the need for manual workspace switching.

---

References:

• How-To: Use variables in custom workloads
• How-To: Store item definition (state)
• Create, configure, and use an environment in Fabric