Power BI Project (PBIP) and Azure DevOps build pipelines for continuous integration

Combining Fabric Git Integration with Azure DevOps, enables you to connect a workspace to a branch in an Azure DevOps repository and automatically synchronizes between them.

Integrating the PBIP format with Azure DevOps lets you use Azure Pipelines to automate Continuous Integration/Continuous Deployment (CI/CD) pipelines. These pipelines process the PBIP metadata files and apply a series of quality checks to your development before deploying it to the production system.

In this article, we focus on continuous integration and describe how to create an Azure DevOps build pipeline that guarantees best practices for all semantic models and reports within a Fabric workspace. By implementing automated quality tests, you can prevent common mistakes, and enhances team efficiency. For example, this approach ensures that new team members adhere to established standards for semantic model and report development.

Learn more about PBIP and Fabric Git Integration in project-overview and Fabric Git integration overview.

The following diagram illustrates the end-to-end scenario with two development workflows that trigger the Azure DevOps build pipeline to validate development quality. The build execute does the following actions:

Diagram showing workflow of build pipeline.

  1. User 1 develops using Power BI Desktop.

    1. Create a branch from main using VS Code (feature/datasetchange)
    2. Make changes to semantic model using Power BI Desktop
    3. Commit changes to remote repository branch using VS Code
    4. Create Pull Request to main branch using Azure DevOps
  2. At the same time, User 2 develops using another Fabric workspace.

    1. Create branch from main using Fabric Git (feature/reportchange)
    2. Make report changes in the Fabric workspace
    3. Commit changes to remote repository branch using Fabric Git
    4. Create Pull Request to main branch using Azure DevOps
  3. The team lead reviews the Pull Requests and synchronizes the changes to the team workspace using Fabric Git.

  4. The Pull Request triggers the Azure DevOps build pipeline to inspect the semantic model and report development quality.


In this example, the build pipeline uses two open-source community tools that enable a developer to apply (customizable) best practice rules to the metadata of semantic models and reports within a Power BI Project folder:

An approach similar to the example in this article would apply to other community tools. This article doesn't delve into the specifics of the community tools mentioned previously nor rule creation and editing. For in-depth information on these topics, refer to the links provided. The focus of this article is on the process of establishing a quality gate between source control and Fabric Workspace. It's important to note that the referred community tools are developed by third-party contributors, and Microsoft does not offer support or documentation for them.

Step 1 - Connect Fabric workspace to Azure DevOps

Connect your Fabric workspace to Azure DevOps:

Screenshot showing the Git connection to DevOps.

When Fabric Git integration finishes exporting your workspace items, your Azure DevOps branch will contain a folder for each item in your workspace:

Screenshot showing the Azure DevOps branch with folders for different workspace items.

Step 2 - Create and run an Azure DevOps build pipeline

To create a new build pipeline:

  1. From the Pipelines tab of the left navigation menu, select Create Pipeline :

    Screenshot showing how to create a pipeline.

  2. Select Azure Repos Git and select the first repository (the same repository that's connected to the Fabric workspace):

    Screenshot showing Azure repo Git selected as the code source for the pipeline.

    Screenshot showing the Demo-ADObuild repo selected.

  3. Select Starter pipeline.

    Screenshot showing the starter pipeline icon selected.

    The following YAML code appears in the editor:

    Screenshot showing the default YAML code.

  4. Copy and paste the YAML code from the Power BI developer mode pipeline into the pipeline you created:

    Screenshot showing YAML code to be added.

    Screenshot showing second part of YAML code.

  5. Select Save and Run to commit your new pipeline to the repository.

    Screenshot of a review of the YAML code.

    Screenshot showing save and run selection.

Azure DevOps runs the pipeline and starts two build jobs in parallel:

Screenshot showing Azure DevOps building a pipeline.

  • Build_Datasets
    • Downloads Tabular Editor binaries.
    • Download Best Practice Analyzer default rules. To customize the rules, add a Rules-Dataset.json to the root of the repository.
    • Cycle through all the semantic model item folders and run Tabular Editor BPA Rules.
  • Build_Reports
    • Download PBI Inspector binaries.
    • Download PBI Inspector default rules. To customize the rules, add a Rules-Report.json to the root of the repository.
    • Cycle through all the report item folders and run Power BI Inspector rules.

When it finishes, Azure DevOps creates a report of all the warnings and errors it encountered:

Screenshot showing error report.

Select on the link to open a more detailed view of the two build jobs:

Screenshot showing view log button.

Screenshot showing expanded error log.

If your report or semantic model fails a rule with a higher severity level, the build fails, and the error is highlighted:

Screenshot showing highlighter errors.

Step 3 - Define branch policies

Once the pipeline is up and running, enable Branch Policies on the main branch. This step ensures that no commits can be made directly into main. A "pull request" is always required to merge changes back into main and you can configure the build pipeline to run with every pull request.

  1. Select Branches > main Branch > Branch policies:

    Screenshot showing branch policies.

  2. Configure the created pipeline as a Build Policy for the branch:

    Screenshot showing the build policy UI.

    Screenshot showing second part of the build policy UI.

Step 4 - Create pull request

If you return to your Fabric Workspace, make a modification to one of the reports or semantic models, and attempt to commit the change, you receive the following error:

Screenshot showing the unable to commit change error.

You can only make changes to the main branch through a pull request. To create a pull request checkout a new branch to make the changes on:

Create a branch directly from the Fabric Workspace:

  1. In the Source Control pane, select on Checkout new branch and provide a name for the branch.

    Screenshot showing the source control screen to checkout a new branch.

    Screenshot showing how to checkout a new branch.

    Alternatively, you can choose to develop within a separate, isolated workspace or in Power BI Desktop. For more information, see develop using another workspace

  2. Commit your changes to this new branch.

    Screenshot showing commit changes to branch.

  3. Following the commit, create a pull request into the main branch from the Azure DevOps portal.

    Screenshot showing a new pull request created.

    Screenshot showing created pull request.

The pull request workflow not only allows you to validate and review the changes, but also automatically triggers the build pipeline.

Screenshot showing report change.

If there's a high-severity build error in one of the rules, you can't finalize the pull request and merge the changes back into the main branch.

Screenshot completed pull request.

Learn more about PBIP and Fabric Git Integration in blog post.