Best practices for GitHub versioning with Fabric deployment pipelines across dev/test/prod

[ndamoi]

Hello all, I hope you're well!

I'm currently trying to manage my environments using GitHub for version control and Microsoft Fabric's deployment pipelines. I have my development workspace linked to GitHub, specifically to the develop branch. My test and prod workspaces, however, are not linked to the repo—they're only part of the deployment pipeline.

My initial idea was:

• Finish work on develop
• Create a release branch
• Link the test workspace to that release branch
• If testing goes well, merge the release branch into main
• Link the prod workspace to main

But now I’m realizing this might not be the right approach. The deployment pipeline doesn’t seem to recognize files from different branches, and I’m concerned that unsupported items (for git) might not deploy (via pipelines) properly when switching branches. I also worry about breaking workspace tracking if I manually switch branches or link workspaces outside the pipeline.

I was interested in using the Git Flow concept to manage features, releases, and hotfixes, but I’m a bit lost on how to align that with Fabric’s deployment model. For example:

• If prod needs a hotfix, should I create a new workspace linked to the release branch?
• How do I deploy that fix to test if the new workspace isn’t part of the pipeline? (if sticking to deploying via pipelines)

Lastly, I’m wondering: do I even need Git versioning on test and prod workspaces, or is it enough to version control only the dev workspace and manage release/hotfix branches in GitHub or locally via client tool or commands ?

Any advice, best practices, or examples of how you’ve handled this would be hugely appreciated.

Thanks in advance!!!

[v-ssriganesh · Accepted solution]

Hello @ndamoi,
Thank you for reaching out to the Microsoft Fabric Community Forum. Please consider the below points:

• Connect your development workspace to the develop branch in GitHub for version control. Use feature branches for new work, merging into develop via pull requests (PRs) to ensure collaboration and code quality. Sync the dev workspace after merges to reflect changes.

• Deploy content from dev to test, then test to prod, using Fabric deployment pipelines instead of linking test/prod workspaces to Git. This avoids synchronization issues from manual branch switching and leverages pipelines for controlled consistent deployments.
• For releases, create a release/v1.0.0 branch from develop, deploy from the dev workspace to test via the pipeline and validate changes. After testing, merge the release branch into main and deploy from test to prod using the pipeline, ensuring a stable production rollout.
• For hotfixes, create a hotfix/v1.0.1 branch from main. Develop and test in the dev workspace or a temporary one, then merge into main and develop. Deploy to test and prod via the pipeline, eliminating the need for new workspaces unless isolation is critical.
• Use separate databases for dev/test/prod to protect production data. Apply parameters and deployment rules for environment-specific configurations (e.g., data sources). Make small, frequent commits to minimize conflicts, and consider GitHub Actions to automate PR validation and pipeline deployments for efficiency.

Refer the below official docs:

• Best Practices for CI/CD
• Introduction to Deployment Pipelines
• Git Integration and Deployment Pipelines
• Manage Deployment

Best regards,
Ganesh Singamshetty.

[ndamoi]

Hello @v-ssriganesh ,
Thank you so much for your helpful response!

If I got it right, I should manage branches in GitHub and use deployment pipelines to handle workspace transitions. That makes things much clearer.

I’ll follow your best practices and check out the links you shared—really appreciate your support!