Power BI CI/CD: From Manual Publishing to Automated Deployments

Deployment to the Power BI Service can be done using both Azure DevOps and GitHub, but many teams prefer GitHub because it is open-source, widely adopted, and easy to integrate with automation tools. This often leads to common questions such as: What is CI/CD? What is a CI/CD pipeline? And why use CI/CD when manual publishing already works? In this blog, we answer these questions and explain how a GitHub-based CI/CD pipeline enables automated and reliable Power BI deployments.

CI/CD (Continuous Integration and Continuous Deployment) is a development approach where changes are regularly stored in source control and automatically deployed to the target environment. In simple terms, it helps teams release updates faster, with fewer manual steps and better consistency.

Why CI/CD Pipelines Are Important for Power BI

As Power BI solutions grow, manual deployments become risky and hard to manage. They can lead to accidental overwrites, inconsistent versions across environments, and poor traceability. A CI/CD pipeline solves these problems by automating how reports and datasets move from source control to the Power BI Service. This ensures consistent deployments, reduces human error, and supports enterprise needs such as governance and controlled releases.

Automating Power BI Deployments Using GitHub CI/CD

As Power BI environments grow, deployments need to become automated, repeatable, and secure. A GitHub-based CI/CD pipeline enables this by eliminating manual steps and enforcing a consistent deployment process. By combining GitHub Actions, Azure App Registration, and the Power BI Service, teams can deploy reports confidently while maintaining control, security, and traceability.

In this blog, we walk through a practical, end-to-end setup that demonstrates how to deploy a Power BI report from GitHub to the Power BI Service using Azure App Registration and GitHub Actions.

High-Level Architecture

The deployment flow looks like this:

Power BI Desktop >> GitHub Repository >> GitHub Actions >> Power BI Service

GitHub acts as the source control and automation engine, while Azure Active Directory (Entra ID) handles secure authentication.

Step 1: Create an App Registration in Azure (Service Principal)

To allow GitHub Actions to deploy content into Power BI Service without user login, we first need to create a Service Principal using Azure App Registration.

Steps:

• Open https://portal.azure.com
• Search for App registrations
• Click New registration
• Provide a name (for example: PBI-Auto-Deploy)
• Select Single tenant
• Click Register
  Once registered, Azure creates an identity for automation.

Step 2: Capture Required IDs (Client ID & Tenant ID)

After registration:

• Navigate to the Overview section
• Copy and store:
  • Application (Client) ID
  • Directory (Tenant) ID

These values are required later for authentication inside GitHub Actions.

Step 3: Generate a Client Secret

The client secret is used by GitHub Actions to authenticate as the application.

Steps:

• Go to Certificates & secrets
• Click New client secret
• Add a description and expiry
• Click Add
• Copy the secret value immediately (it is shown only once)

Step 4: Grant Power BI Workspace Access

To enable automated deployments, the Service Principal created through Azure App Registration must be granted access to the Power BI workspace.

Steps:

• Open Power BI Service
• Create a new workspace (or open an existing one)
• Go to Workspace >> Manage access
• Click Add people or groups
• Add the same email or identity used during Azure App Registration (for example, xyz@oxygenbi.com)
• Assign it the Admin role

After access is granted, copy the Workspace ID from the browser URL.

Without this step, the CI/CD pipeline will fail even if authentication succeeds, because the Service Principal will not have the required permissions to publish reports or datasets to the workspace.

Setting Up GitHub Repository and CI/CD Workflow for Power BI Deployment

Once the Azure App Registration and Power BI workspace access are in place, the next step is to prepare the GitHub repository that will host our Power BI files and the CI/CD pipeline definition. GitHub acts as the central source control system and also runs the automation through GitHub Actions.

This section explains how the repository is structured, why a README is useful, and how the deployment workflow works behind the scenes.

Step 1: Create a GitHub Repository

Now we prepare the GitHub side.

Steps:

• Open GitHub
• Click New Repository
• Provide a name (example: power-auto-deploy)
• Choose visibility
• Create the repository

Upload your PBIX file (or PBIP structure) into this repository.

Step 2: Store Secrets in GitHub

Hardcoding credentials in a repository is unsafe and should always be avoided. GitHub provides encrypted secrets that allow sensitive information to be stored securely and used only during pipeline execution.

Steps:

• Open your GitHub repository and go to Settings
• Navigate to Secrets and variables >> Actions
• Add the following secrets:
  1. PBI_CLIENT_ID >> Application (Client) ID from Azure App Registration
  1. PBI_CLIENT_SECRET >> Client Secret created in Azure
  1. PBI_TENANT_ID >> Azure Tenant ID
  1. PBI_WORKSPACE_ID >> Target Power BI Workspace ID

These secrets are automatically and securely injected into the CI/CD pipeline at runtime, ensuring that no credentials are exposed in the repository or pipeline code.

Adding a README and Creating the CI/CD Pipeline

Once the GitHub repository is created, the next step is to add a README file and set up the CI/CD pipeline that will automate Power BI deployments.

Step 1: Add a README File

The first thing we do is add a README.md file to the repository.
The README acts as a simple introduction to the project and helps anyone who opens the repository understand why this repository exists and what it does.

In our case, the README typically explains:

• This repository is used for automated Power BI deployments
• GitHub Actions is used to deploy reports to Power BI Service
• Azure App Registration (Service Principal) is required for authentication

Adding a README makes the repository self-explanatory and professional, especially in team or enterprise environments.

Step 2: Create the CI/CD Pipeline Folder Structure

GitHub Actions requires a specific folder structure to detect and run pipelines.

Create the following structure inside your repository:

Folder Structure:

.github/
 └── workflows/
     └── deploy.yml

• The .github/workflows folder tells GitHub that this repository contains automation workflows.
• The deploy.yml file defines when the pipeline runs and what steps it executes.
• Inside the deploy.yml file, add the following YAML configuration:

How This CI/CD Pipeline Works (Behind the Scenes)

When a Power BI file is uploaded or updated in the GitHub repository and the change is committed to the main branch, the CI/CD pipeline is triggered automatically. GitHub Actions starts the workflow by spinning up a Windows environment, which is required to run Power BI PowerShell modules. The pipeline first downloads the repository content so it can access the PBIX file and deployment configuration. It then installs the MicrosoftPowerBIMgmt PowerShell module and authenticates to the Power BI Service using the Service Principal created through Azure App Registration. The authentication securely uses the Client ID, Tenant ID, and Client Secret stored in GitHub Secrets. Once authenticated, the pipeline publishes the PBIX file to the specified Power BI workspace, overwriting the existing report if it already exists. This entire process runs automatically in the background, ensuring consistent and reliable deployments without any manual publishing.

What Is a Service Principal and Why Is It Used?

A Service Principal is a non-human identity created in Azure that allows automation tools to securely access Microsoft services without using a personal user account. It is created through Azure App Registration and represents the application inside Azure and the Power BI Service.

In a CI/CD setup, the pipeline uses the Service Principal to authenticate programmatically with a Client ID, Tenant ID, and Client Secret, instead of a username and password. This enables tools like GitHub Actions to deploy Power BI reports automatically. Service Principals are used because they provide secure, user-independent access, support credential rotation, and meet enterprise requirements such as governance and auditability.

Conclusion

Automating Power BI deployments using a GitHub-based CI/CD pipeline brings modern DevOps practices into BI development. While manual publishing may work in small setups, it quickly becomes unreliable as solutions grow and teams scale. By using GitHub Actions, Azure App Registration, and Power BI Service, deployments become automated, secure, and repeatable. This approach not only reduces deployment errors and improves consistency across environments but also supports enterprise requirements such as governance, auditability, and controlled releases.