azure-devopscontinuous-integrationcicdmicrosoft-fabric

Benefits of using Fabric-ADO Pipeline over Inbuilt MS Fabric Deployment pipeline

I am trying to understand for what use cases we would consider using Fabric-Azure DevOps Pipeline using API's over Inbuilt MS Fabric Deployment pipeline. What are the benefits under what scenario.

One benefit maybe I see is certain file types are not supported for deployment to next stage in Fabric such as SQL analytics endpoint and dataflow. But I need confirmation if API's will mitigate this issue.

enter image description here

Solution

  • Microsoft has published recommendations for different CI/CD strategies using Fabric. The strategies depend greatly on your team, solution and organizational structure. Kevin Chant, MS MVP, has a good overview of these topics in this video.

    At a high-level the guidance outlines four different options.

    1. Git-based deployments. Each environment is connected to a branch that uses git integration. Azure DevOps pipelines can be used to provide build validation for pull-requests between branches. You might need to alter configuration settings in an environment post-synchronization using an API.

      Option 1 Diagram

    2. Git-based deployments using Build Environments. Here, Azure Pipelines is used to build and deploy changes into your environments. Environment specific settings are applied pre-deployment.

      Option 2 Diagram

    3. Deploy using Fabric Pipelines. Only the developer environments are git-integrated, and changes to higher environments are promoted using Fabric pipelines. This can be automated using Fabric deployment APIs.

      Option 3 Diagram

    4. CI/CD for ISVs. Similar to Option 2, but geared towards multi-tenant solutions where there are potentially hundreds of environments.

      Option 4 Diagram

    Also understand that Azure DevOps is concerned with the entire software delivery lifecycle, such as work item management, source-control, testing, and build and release. All members of your team should have access and collaborate on the work.

    Fabric's deployment pipelines are great, they're based on PowerBI pipelines and have been around for a while. No doubt, they're going to get better over time as new features are added. However, not all team members of your project will (or should) have access to these pipelines.

    In my opinion, the tool access is where the intersection of the two platforms meet. As implied by the use of Fabric deployment APIs in Option 3, you can use Azure Pipelines to automate the content promotion and use deployment gates (approvals, business hours, etc) to control when it happens. You can also augment the deployment process with custom automation to overcome gaps in the Fabric Pipelines.