Forum Discussion
Best practices for Fabric Git integration with DEV and PROD
Hi Fabric Community,
I am implementing a Fabric solution with two separate workspaces:
DEV workspace connected to the develop branch
PROD workspace connected to the main branch
Changes are developed and tested in DEV, then promoted to PROD through a pull request. No direct development changes are made in production.
The main challenge is environment-specific bindings.
Both workspaces contain Lakehouses with the same names but different workspace and item IDs. Git synchronization does not always update these references automatically.
For Data Pipelines, Copy activities contain specific workspaceId and artifactId values, so a synchronized pipeline may still point to the wrong environment.
For now, I have decided to maintain separate pipelines:
DEV:
- pipeline_name_dev
- Copy destinations point to the DEV Lakehouse
PROD:
- pipeline_name
- Copy destinations point to the PROD Lakehouse
I also use separate DEV and PROD Variable Library value sets and validate the expected workspace and Lakehouse before writing data.
How do you handle this in your Fabric projects?
Do you maintain separate DEV and PROD pipelines?
Do you update bindings with REST APIs or deployment scripts?
Do you use Git integration together with Deployment Pipelines?
How do you verify that all items point to the correct environment after synchronization?
Hi jaryszek ,
Thank you for reaching out to Microsoft Fabric Community Forum your overall approach is correct The main recommendation is to automate the validation of environment-specific references as part of the deployment process to ensure that PROD artifacts never point to DEV resources below are the few points
- The current Git branching strategy is appropriate DEV workspace → develop branch, PROD workspace → main branch.
- Development and testing are performed in DEV Environment Changes are promoted to PROD through a Pull Request.
- No direct development changes are made in PROD.
- Use Git Integration for source control and Deployment Pipelines for environment promotion.
- Do not rely solely on Git synchronization to automatically update all environment-specific references, especially Workspace IDs ,Lakehouse Item IDs, Pipeline artifact references, Other environment-specific bindings.
- Matching Lakehouse names do not guarantee that the references are correct because DEV and PROD Lakehouses have different Workspace IDs and Item IDs.
- For Data Pipelines, verify that Copy activities reference the correct environment:
- DEV → DEV Workspace ID + DEV Lakehouse ID.
- PROD → PROD Workspace ID + PROD Lakehouse ID.
- Use parameters, Variable Libraries, and deployment rules wherever supported to manage environment-specific configuration.
- Maintaining separate DEV and PROD pipelines is a valid workaround when the specific Lakehouse binding cannot be reliably parameterized or automatically remapped during deployment.
- If separate pipelines are maintained, ensure that they are kept functionally identical and that only the environment-specific configuration differs.
- REST APIs or deployment scripts can be used where appropriate to automate validation and, where supported, update environment-specific configuration.
The current approach of maintaining separate DEV and PROD pipelines is acceptable if Fabric cannot reliably remap the Lakehouse bindings. The preferred long-term approach is to minimize duplicated pipelines, use environment-specific configuration wherever supported, and automate post-deployment validation of Workspace IDs and Lakehouse IDs. This reduces the risk of a PROD pipeline accidentally writing data to the DEV environment.
Thanks,
Chaithanya.
3 Replies
Hi jaryszek ,
Thank you for reaching out to Microsoft Fabric Community Forum your overall approach is correct The main recommendation is to automate the validation of environment-specific references as part of the deployment process to ensure that PROD artifacts never point to DEV resources below are the few points
- The current Git branching strategy is appropriate DEV workspace → develop branch, PROD workspace → main branch.
- Development and testing are performed in DEV Environment Changes are promoted to PROD through a Pull Request.
- No direct development changes are made in PROD.
- Use Git Integration for source control and Deployment Pipelines for environment promotion.
- Do not rely solely on Git synchronization to automatically update all environment-specific references, especially Workspace IDs ,Lakehouse Item IDs, Pipeline artifact references, Other environment-specific bindings.
- Matching Lakehouse names do not guarantee that the references are correct because DEV and PROD Lakehouses have different Workspace IDs and Item IDs.
- For Data Pipelines, verify that Copy activities reference the correct environment:
- DEV → DEV Workspace ID + DEV Lakehouse ID.
- PROD → PROD Workspace ID + PROD Lakehouse ID.
- Use parameters, Variable Libraries, and deployment rules wherever supported to manage environment-specific configuration.
- Maintaining separate DEV and PROD pipelines is a valid workaround when the specific Lakehouse binding cannot be reliably parameterized or automatically remapped during deployment.
- If separate pipelines are maintained, ensure that they are kept functionally identical and that only the environment-specific configuration differs.
- REST APIs or deployment scripts can be used where appropriate to automate validation and, where supported, update environment-specific configuration.
The current approach of maintaining separate DEV and PROD pipelines is acceptable if Fabric cannot reliably remap the Lakehouse bindings. The preferred long-term approach is to minimize duplicated pipelines, use environment-specific configuration wherever supported, and automate post-deployment validation of Workspace IDs and Lakehouse IDs. This reduces the risk of a PROD pipeline accidentally writing data to the DEV environment.
Thanks,
Chaithanya.
thanks, post-deployment autimation - how? Git actions? or notebooks somehow?
HI jaryszek ,
GitHub Actions + Fabric REST APIs is the preferred approach for automated post-deployment validation. A Fabric Notebook + Fabric Pipeline is a good alternative if you want the validation process to remain entirely within Fabric.
Thanks,
Chaithanya.
