Best practices for Fabric Git integration with DEV and PROD

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.