Forum Discussion
CI/CD deployment for arbitrary workspaces without Fabric Git Integration
Hi User,
Your understanding is largely correct. Today, Fabric Git Integration is the recommended experience for source control and CI/CD, but it is primarily designed around a workspace-to-branch model. For ISV scenarios requiring any branch → any workspace deployments and GitHub Enterprise environments that Fabric cannot access, there isn't currently a fully equivalent "code-first" deployment model for all Fabric artifact types.
For enterprise CI/CD without Fabric Git Integration, a common approach is:
Store Fabric artifacts in Git using the Fabric VS Code extension, the Fabric REST APIs, or supported project formats where available.
Use your existing CI/CD platform (e.g., GitHub Actions, Azure DevOps, Jenkins) to determine which branch, tag, or commit should be deployed.
Parameterize environment-specific values (workspace IDs, connection strings, Eventstream resource IDs, etc.) during deployment rather than committing them directly.
For artifacts such as Eventstream that contain environment-specific identifiers, maintaining a templating or parameterization layer (for example, using fabric-cicd with environment-specific parameter files) is currently one of the most practical approaches.
Where supported, leverage deployment pipelines and REST APIs to automate artifact promotion, while recognizing that not every Fabric workload currently offers the same level of deployment portability.
At present, there isn't a built-in mechanism that automatically remaps all environment-specific IDs for every Fabric artifact type during deployment. This is an area where many customers and ISVs have requested improvements.
For more information:
Fabric CI/CD guidance: https://learn.microsoft.com/fabric/cicd/
Fabric REST APIs: https://learn.microsoft.com/rest/api/fabric/
Fabric Git integration: https://learn.microsoft.com/fabric/cicd/git-integration/intro-to-git-integration
Could you also clarify:
Are you targeting all Fabric artifact types, or primarily Data Factory, Eventstream, and Real-Time Intelligence artifacts?
Are your customer workspaces located in different tenants, or within a single tenant?
Have you evaluated the open-source fabric-cicd tooling, and if so, are there specific artifact types where you've found its parameterization insufficient?
These details would help determine whether there's an alternative deployment pattern that better fits your architecture.
💡 Helpful? Give a Kudos 👍 — keep the community growing.
✅ Solved your issue? Mark this as the Accepted Solution ✔️
Best regards,
Prince Singh | Data Science & Microsoft Fabric Enthusiast
Hi User,
Your understanding is largely correct. Today, Fabric Git Integration is the recommended experience for source control and CI/CD, but it is primarily designed around a workspace-to-branch model. For ISV scenarios requiring any branch → any workspace deployments and GitHub Enterprise environments that Fabric cannot access, there isn't currently a fully equivalent "code-first" deployment model for all Fabric artifact types.
For enterprise CI/CD without Fabric Git Integration, a common approach is:
Store Fabric artifacts in Git using the Fabric VS Code extension, the Fabric REST APIs, or supported project formats where available.
Use your existing CI/CD platform (e.g., GitHub Actions, Azure DevOps, Jenkins) to determine which branch, tag, or commit should be deployed.
Parameterize environment-specific values (workspace IDs, connection strings, Eventstream resource IDs, etc.) during deployment rather than committing them directly.
For artifacts such as Eventstream that contain environment-specific identifiers, maintaining a templating or parameterization layer (for example, using fabric-cicd with environment-specific parameter files) is currently one of the most practical approaches.
Where supported, leverage deployment pipelines and REST APIs to automate artifact promotion, while recognizing that not every Fabric workload currently offers the same level of deployment portability.
At present, there isn't a built-in mechanism that automatically remaps all environment-specific IDs for every Fabric artifact type during deployment. This is an area where many customers and ISVs have requested improvements.
For more information:
Fabric CI/CD guidance: https://learn.microsoft.com/fabric/cicd/
Fabric REST APIs: https://learn.microsoft.com/rest/api/fabric/
Fabric Git integration: https://learn.microsoft.com/fabric/cicd/git-integration/intro-to-git-integration
Could you also clarify:
Are you targeting all Fabric artifact types, or primarily Data Factory, Eventstream, and Real-Time Intelligence artifacts?
Are your customer workspaces located in different tenants, or within a single tenant?
Have you evaluated the open-source fabric-cicd tooling, and if so, are there specific artifact types where you've found its parameterization insufficient?
These details would help determine whether there's an alternative deployment pattern that better fits your architecture.
💡 Helpful? Give a Kudos 👍 — keep the community growing.✅ Solved your issue? Mark this as the Accepted Solution ✔️Best regards, |
Even a typical fabric-cicd setup seems to require connecting your Fabric workspace to a Git repo at least once to generate the artifact files and folder structure the library expects, unless you recreate them yourself (for example, via the REST APIs or the VS Code extension).
It is also not without its limitations: fabric-cicd doesn't support Workspace settings (i.e., Managed Private Endpoints or Fabric Connections), so you need additional tooling, such as the Terraform Fabric provider, to get everything wired up.
But, as far as I can tell, that's the only realistic option right now.
Hi seihl,
Thanks for the clarification and for sharing your insights. I appreciate you taking the time to explain the current limitations and the available options. This is very helpful and provides good context for anyone exploring similar deployment scenarios.
Thank you.
