Deploy Power Platform solutions with Azure DevOps or GitHub

Pipelines in Power Platform move a solution from development to test and production from inside the maker portal, and for many teams that's enough. You build a pipeline in Azure DevOps or GitHub when you need what those tools add: the solution's source in Git with reviewed changes, deployments to another tenant, your own approval gates, or Power Platform releases alongside the code they call. Microsoft provides the building blocks for both, the Power Platform Build Tools for Azure DevOps and GitHub Actions for Power Platform. This guide covers when to choose them, how they sign in, and the steps they run.

Start with pipelines in Power Platform

Pipelines in Power Platform need no Azure DevOps or GitHub at all: makers deploy a solution from its page, admins set up the stages, and approvals and service-principal deployments are available. They also store each deployed version, so you can redeploy an earlier one when that setting is on. Use Azure DevOps or GitHub instead, or alongside them, when:

• The solution's source must live in Git, unpacked into readable files, so changes are reviewed in pull requests and you can see exactly what changed between releases.
• You deploy to another tenant. Pipelines in Power Platform can't; Microsoft recommends Azure DevOps or GitHub for it.
• Releases need gates you already run in Azure DevOps or GitHub, or the solution ships together with Azure code it depends on.

You don't have to pick one. Pipelines in Power Platform can be extended to call Azure DevOps or GitHub, for example to commit each deployed version to a branch.

If you find the ALM Accelerator in older guidance: Microsoft has deprecated it and points to pipelines in Power Platform instead.

Azure DevOps or GitHub

Both cover the same solution steps, a solution checker step, and tasks to manage environments.

Connect with a service principal

1. Register an app in Microsoft Entra ID for the pipeline. For Azure DevOps, prefer a service connection that uses workload identity federation, so there's no secret to store; for GitHub, create a client secret and note when it expires.
2. Add it as an application user in every environment the pipeline touches (development, test, production), in the Power Platform admin center, with a security role that lets it export and import solutions.
3. Create the connection: in Azure DevOps, a service connection of type Power Platform for each environment; in GitHub, repository secrets holding the app ID, tenant ID and client secret.

User name and password connections still exist, but they don't support multifactor authentication, so they break in any tenant that requires it.

The pipeline in four steps

1. Export the solution from development, as unmanaged for source control and as managed to deploy. Use the solution's name, not its display name. Many teams first set the solution version from the build number, with the Set Solution Version task.
2. Unpack the unmanaged export into source control. The exported zip isn't suitable for Git; unpacking turns it into files that show readable differences in a pull request. (The pack step turns those files back into a solution zip when you build from Git.)
3. Check the solution with the solution checker step, which catches common problems before anything is deployed.
4. Import the managed solution into test, then production. A deployment settings file fills in each environment's connection references and environment variable values, so nobody edits them by hand after the import.

Deploy managed solutions everywhere except development; Microsoft recommends it, and it keeps test and production from being edited directly.

Things that catch people out

• Managed Environments for pipeline targets. Starting in October 2026, when pipelines in Power Platform deploy to a target that isn't a Managed Environment, admins are notified and have 30 days to approve enabling it before further deployments to it are blocked.
• The deploying identity owns what it deploys. Microsoft states it for pipelines in Power Platform: deploy with a service principal, and the service principal owns the deployed objects. Give it its role in each environment before the first run.
• Client secrets expire, and the GitHub workflow or secret-based Azure DevOps connection stops when they do. Track the date, or use workload identity federation in Azure DevOps.

Sources

• Microsoft Power Platform Build Tools for Azure DevOps, Microsoft Learn
• Microsoft Power Platform Build Tools tasks, Microsoft Learn
• GitHub Actions for Microsoft Power Platform, Microsoft Learn
• Available GitHub Actions for Microsoft Power Platform development, Microsoft Learn
• Overview of pipelines in Power Platform, Microsoft Learn
• Extend pipelines in Power Platform, Microsoft Learn
• Pre-populate connection references and environment variables for automated deployments, Microsoft Learn