CI/CD for planning in Fabric

Use CI/CD (Continuous Integration and Continuous Deployment) to streamline the development and deployment of planning content across environments. Integrate planning artifacts into source control, validate changes, and deploy updates consistently from development to production while reducing manual effort and deployment errors.

Planning supports two key CI/CD capabilities: Git integration and deployment pipelines. These tools help manage planning items across development, test, and production environments by allowing individual items to be deployed, or multiple items to be deployed at once.

In addition, Planning supports using variables to dynamically manage semantic models, writeback destinations, and writeback connections across environments.

Configure Git integration#

Planning integrates with source control at the workspace level. You can commit all planning items in a workspace to a Git branch and version multiple planning items through a single process. The workspace structure, including folders, is preserved in the Git repository. Fabric supports source control through GitHub and Azure DevOps. For more information, see Fabric Git Integration.

1. Open the Fabric workspace to integrate with a Git repository.
2. Go to Workspace Settings and select Git integration.
3. Select your source control provider: Azure DevOps or GitHub.

4. Enter the Azure DevOps or GitHub account and repository details. In this example, you choose Github.
5. Select Connect.
6. In the Connect Git repository and branch section, select an existing branch or create a new branch.

7. Select Connect and Sync.
8. Fabric displays the branch, sync status for each item, and the time of the last sync.

Commit changes to the Git repository#

When you make changes to an existing plan, delete, or create a new plan, you must commit them to the Git repository linked to that workspace. The status of modified items changes to Uncommitted.

1. Select the Source control option.

2. Select the Changes tab from the Source control side pane. This tab displays all the items you changed, with an icon indicating the status: New , Modified , Conflict , or Deleted .
3. Select the items to commit to the Git repository and add an optional commit message. Select Commit.

4. After the selected items are committed to the Git repository, they are removed from the list. The item status changes to Synced, and the status bar displays the latest commit.

Deploy planning items to other workspaces#

Create a deployment pipeline to promote plan items from development to test and production workspaces. To know more about deployment pipelines in Fabric, see Introduction to deployment pipelines.

Fabric’s lineage view helps you track item dependencies. For CI/CD deployments, if a plan depends on a semantic model, you must deploy that semantic model to the target workspace at least once using a deployment pipeline. This ensures Fabric maintains the connection to the semantic model in the target workspace.

The following steps describe how to deploy a plan when the plan and semantic model reside in the same workspace and are part of the same deployment pipeline.

1. Commit your plan and semantic model to the Azure DevOps or GitHub repository connected to the workspace.
2. Create a new deployment pipeline, define the pipeline stages, and assign the designated workspaces to each stage.
3. Select the target stage, such as Test or Production, to deploy your planning item. Deploy from is automatically set to the previous stage in the pipeline (For example, Development when deploying to Test). Select the plan the Fabric SQL app DB, and the related semantic model to deploy to the next stage.

4. Select Deploy and verify the source and target stages and the items selected for deployment. Verify that the deployment is successful from the Deployment history pane.

5. Open the target workspace and refresh the semantic model.

6. Open the plan in the target workspace. Fabric automatically retains the semantic model connection and loads the data.

Deploy planning items with stand-alone semantic models#

If your semantic model resides in a separate workspace outside any deployment pipeline, you only need to deploy the plan from your source workspace to the target workspace. Fabric automatically preserves the connection to the stand-alone semantic model in the target workspace.

1. Commit your plan to the Azure DevOps or GitHub repository connected to the workspace.
2. Open the deployment pipeline connected to the workspace. Select the plan and deploy it to the target workspace.

3. Once you deploy the plan to the target workspace, Fabric automatically connects it to the semantic model in the stand-alone workspace and loads the data.

Deploy planning items using models from a different deployment pipeline#

If your semantic model and plan are part of different pipelines, they need to be deployed individually. To successfully deploy your plan, first deploy its semantic model to the target pipeline stage in its own deployment pipeline. This ensures the plan connects to the correct model version upon promotion.

To demonstrate this scenario, consider a planning item named Plan_2 created in the Plan Docs workspace.

• Plan_2 connects to the Enterprise - Sales Transactions semantic model in the Org Semantic Models workspace.
• Plan_2 is part of the DP_Fabric_Planning deployment pipeline.
• The Org Semantic Models workspace is part of a different deployment pipeline - semantic_model_pipeline.

1. Commit the semantic model and plan to the Git repository connected to their respective workspaces.
2. As the semantic model is in a different workspace and pipeline, use its own deployment pipeline to deploy it to the target stage.

3. After the semantic model is successfully deployed, open the target workspace and refresh the semantic model.

4. Promote the plan to the next stage using its dedicated deployment pipeline.

5. Open the plan in the target workspace. Although the semantic model is in a different workspace, the plan seamlessly connects to the semantic model and loads data.

Use variable libraries to connect to semantic models#

Create variables to dynamically assign the semantic model the plan uses across different environments. To learn more about variable libraries see Variable library overview.

For demonstration purposes, consider a deployment pipeline with three stages. In the dev and test stages, the plan connects to the same semantic model. In the prod workspace, the plan connects to another semantic model.

1. Create a variable library in the workspace assigned to the first stage of the deployment pipeline. In this example, the Plan Docs workspace.
2. Add a new variable and set the type to Item reference. Select the semantic model from the development (first pipeline stage) workspace as the Default value set.

3. Select Add value set, then select the semantic model for the target stage (e.g., UAT or production). In this example, you assign the Enterprise - Txn - PROD semantic model to the production environment. Repeat this step to configure different semantic models for additional stages as needed.

4. Create a new plan item and select the Variable Library option when you connect to the semantic model. Select the variable configured in steps 2 and 3.

5. Commit the variable library and plan item to the configured Git repository.
6. Deploy the variable library to the next stage (test) in the pipeline.
7. In this example, you use the same semantic model in the test stage, so the variable library doesn't need to be updated after migrating to test - it uses the same active set as development. Deploy the plan item after the variable library is successfully deployed.
8. Deploy the variable library to the target stage (e.g., Production). If that stage requires a different semantic model, open the variable library in the target workspace (e.g., Plan Docs [PROD]), set the target value set that contains the required values as active, and save your changes. In this example, you set the PROD value set to active.

9. Migrate the plan to the target environment.
10. Open the plan in the target (Plan Docs [PROD]) workspace. It automatically connects to the semantic model designated as the active set in the variable library.

Migrate writeback destinations#

To migrate the Fabric SQL writeback destination database, see SQL database source control integration in Microsoft Fabric.

The writeback destination configuration is preserved during deployment, but the generated target table name will initially display as a system-generated ID. You can manually rename the table and execute writeback.

• Writeback logs: Execution logs from the source workspace are not transferred to the target workspace. Any writeback activity in the target workspace will be logged as a new, independent event.
• Auto-Writeback and baselining: If Auto-Writeback is enabled, the initial writeback attempt in the target workspace will fail when cell values are updated. This occurs because baseline data has not yet been established. To resolve this, perform a manual writeback in the target workspace first; subsequent Auto-Writeback operations will then function normally.

Use variables for writeback destinations and connections#

Using variables for writeback connections and SQL destinations simplifies environment management across CI/CD stages like Dev, Test, and Prod. Instead of manually reconfiguring database settings in each workspace after deployment, variables dynamically route data to the correct database based on the active set in the variable library.

1. In the variable library, create two variables:

• An Item Reference variable to store the writeback destination database.
• A Connection Reference variable to store the database connection.

2. Open your planning or sheet or matrix visual in an intelligence sheet and configure the writeback destination. In the connection dropdown, select Use Variable and select the connection reference variable created in the variable library.

3. Set Select Database From to Variable Library, then select the database item reference variable created in the variable library.

4. When you deploy the plan to other stages in the deployment pipeline, the writeback configuration is automatically fetched from the active set for that stage in the variable library.