Custom Microsoft Fabric CI/CD Pipeline for Multi-Tenant SaaS

Overview

Our client, a SaaS product company built on Microsoft Fabric, needed a reliable and scalable way to deploy analytics content across multiple customer tenants — each with different service tiers, feature sets, and upgrade preferences. After evaluating Fabric's native deployment pipelines, critical limitations made it unfit for a multi-tenant SaaS model. NeenOpal designed and implemented a fully custom CI/CD pipeline using GitHub Actions and the Fabric REST APIs, giving the team complete control over what gets deployed, to whom, and when.

Faster Customer Deployments

Faster Updates Propagation

80%

Faster Rollbacks Incase of Issues

Customer Challenges

The team initially explored Microsoft Fabric's built-in deployment pipelines as the foundation for their CI/CD workflow. While the native tooling worked well for simple, single-tenant deployments, it fell short in several critical areas for a multi-tenant SaaS product.

No Selective or Customer-Specific Deployment:

Fabric's native pipeline synced all content within a workspace at once, with no ability to deploy only specific components or tailor deployments to individual customer tiers. For a product serving customers across different service levels, each expecting only the features relevant to their plan, this all-or-nothing approach was unworkable.

No Branch-Level Workspace Isolation

Each workspace in Fabric's native pipeline could not be assigned its own version-control branch, making it difficult to manage different product versions side by side and maintain proper isolation between development, testing, and production environments across multiple tenants.

Lakehouses with Shortcuts Could Not Be Created Automatically

The native pipeline was unable to create Lakehouses with Shortcuts during deployment, requiring manual setup every time a new environment was provisioned. This introduced operational overhead, inconsistency across environments, and a dependency on manual intervention that defeated the purpose of automated deployment.

Custom Library Environments Caused Indefinite Hangs

Deploying Environments that included custom code libraries caused the pipeline to hang indefinitely, no error, no completion, just an unresponsive process. This made it impossible to reliably deploy pre-configured library dependencies as part of the automated workflow.

Solutions

NeenOpal designed and built a fully custom CI/CD pipeline that replaced Fabric's native deployment tooling with a script-driven, API-first architecture, delivering precise, tenant-aware deployments at every stage of the release cycle.

01.

Artifact Syncing via GitHub and Fabric REST APIs

Fabric artifacts were synced to a GitHub repository using a custom script orchestrated through GitHub Actions and the Fabric REST API. This established full version control and branch-level isolation for every component, giving the engineering team a reliable source of truth and a clear audit trail for every change made to the product.

02.

Versioned Release Creation with GitHub Actions

A GitHub Action packaged the synced artifacts into versioned releases, each representing a tested and approved state of the product. This enabled controlled promotion across environments and made rollbacks straightforward, any previous release could be redeployed instantly without manual recovery effort.

03.

Programmatic Control via Fabric REST APIs

All deployment operations including provisioning, artifact syncing, and configuration were handled programmatically through the Fabric REST APIs, with Service Principal authentication enabling secure, automated execution. This gave the team complete control over what was deployed and where, resolving every limitation encountered with the native pipeline.

04.

Multi-Stage Environment Promotion

The deployment workflow followed a structured four-stage progression: local Spark testing on individual engineer machines, deployment to a shared DEV environment, promotion to a dedicated QA environment for quality checks, and finally controlled PROD deployment to customers on their own schedule. Each stage used the same script, ensuring consistency and reducing the risk of environment-specific failures reaching production.

05.

Controlled Tenant Deployment via Custom Web Application

Rather than automating deployments on a push trigger, deployments were intentionally initiated through a custom web application. This gave the team the ability to deploy on a per-tenant basis, notifying customers when a new version was available and deploying it on their chosen schedule. The same proven deployment script was used consistently across DEV, QA, and PROD environments, eliminating environment-specific discrepancies.

Build scalable, production-ready deployment pipelines with confidence

Talk to an Expert

Services

Microsoft Fabric

GitHub

GitHub Actions

Apache Spark

Benefits

Dramatically Faster Deployments

Customer deployment time was reduced from hours to minutes, and QC turnaround improved from days to hours, eliminating configuration issues that previously required manual intervention after every release.

Instant Rollbacks

With every release versioned in GitHub, the team could roll back to any previous state instantly in the event of a production issue, replacing what previously required days of manual recovery with a single, reliable operation.

Customer-Controlled Upgrades

Customers were never forced into an update. They received notifications when a new version was ready and chose when to adopt it on their own schedule, minimizing operational disruption and giving enterprise clients the control they expected.

Tier-Based Feature Delivery

Each customer received only the features and components relevant to their service tier, delivered through the same automated pipeline without requiring custom deployment logic for each tenant, making onboarding new customers fast and scalable.

Engineering Consistency and Auditability

A single deployment script used across all environments eliminated environment-specific bugs and ensured that what was tested in QA was exactly what reached production. Every change was tracked in GitHub, maintaining a complete, reviewable audit trail for compliance and debugging.

Conclusion

By architecting a custom CI/CD pipeline on top of Microsoft Fabric's REST APIs and GitHub Actions, NeenOpal gave the client's SaaS product a deployment infrastructure that matched the real demands of multi-tenant delivery. The solution resolved every limitation of Fabric's native tooling, accelerated release cycles, and empowered customers with upgrade control, transforming deployment from a source of friction into a competitive advantage.

FAQ

Here are answers to some common questions about the deployment approach, its limitations, and how the custom solution addresses real-world SaaS requirements:

Why wasn't Microsoft Fabric's native deployment pipeline sufficient?

Fabric's built-in pipeline follows an all-or-nothing deployment model with no support for tenant-specific feature delivery, no branch-level workspace isolation, and critical gaps around Lakehouse Shortcuts and custom library environments. For a multi-tenant SaaS product with differentiated service tiers, these limitations made the native tooling unfit for production use.

How does the custom pipeline handle deployments for different customer tiers?

The pipeline deploys only the components and features relevant to each customer's service tier, triggered on a per-tenant basis through a custom web application. This means customers on a standard plan receive their configured feature set while advanced-tier customers receive additional capabilities, all delivered through the same automated workflow without custom logic per tenant.

How are rollbacks handled if something goes wrong in production?

Because every release is versioned in GitHub, rolling back to a previous state requires redeploying the corresponding release using the same deployment script. This replaces a previously manual, multi-day recovery process with an instant, controlled operation, significantly reducing the blast radius of any production issue.