ALM with GitHub Actions for Power Platform

GitHub Actions is the second canonical CI/CD path for Power Platform — equivalent in capability to Azure DevOps, increasingly preferred for new projects given GitHub's broader developer mindshare and the integration with the rest of the GitHub ecosystem.

The Power Platform Actions. Microsoft publishes an official GitHub Actions collection — microsoft/powerplatform-actions — covering the same surface as the Azure DevOps Build Tools:

• actions-install — install the pac CLI on the runner.
• actions/who-am-i — authenticate and verify access to a Power Platform environment.
• actions/export-solution — export solution.zip from an environment.
• actions/pack-solution / actions/unpack-solution — convert between .zip and source folder.
• actions/import-solution — push a solution into an environment.
• actions/publish-solution — publish customisations.
• actions/check-solution — run Solution Checker.
• actions/upgrade-solution — managed solution upgrade flow.
• actions/reset-environment — wipe a sandbox.
• actions/copy-environment — clone an environment.

These are composable in .github/workflows/ YAML files.

Typical workflow. A standard repo would have:

• .github/workflows/ci.yml — runs on PR and main commits. Packs the solution, runs solution checker, runs any unit tests, publishes an artefact.
• .github/workflows/deploy-uat.yml — manually triggered or auto on main merge. Imports the latest packaged solution to UAT.
• .github/workflows/deploy-prod.yml — manually triggered with approval gate. Imports to production.

Authentication. Two patterns:

• Service principal — register an app in Entra ID, configure secrets in GitHub repository settings. The workflow authenticates with client ID + secret (or certificate, preferred for higher security).
• OIDC / federated identity — newer approach. GitHub Actions issues a short-lived OIDC token to Azure; Azure validates and grants access. No long-lived secrets to manage; rotation is automatic.

OIDC is the recommended pattern for new repositories.

Environments and protection rules. GitHub Actions environments correspond to Power Platform environments. Each GitHub environment can have:

• Protection rules — required reviewers before a workflow targeting this environment runs.
• Deployment branches — only allow deploys from specific branches.
• Environment-specific secrets — separate credentials per environment.
• Wait timers — delay deployment to allow review window.

A typical setup: PR workflows run on any branch; deploys to UAT require merge to main; deploys to Production require manual approval and only from main.

Source structure. Same as Azure DevOps — unpacked solution as folders of YAML / XML / JSON files in source control, with pac solution pack reconstructing the .zip at build time.

ALM for non-solution work. Some Power Platform work doesn't live in solutions cleanly: SharePoint configuration, Office 365 tenant settings, Azure resources, custom connector definitions. GitHub Actions handles these too via:

• Azure CLI — provision Azure resources.
• Microsoft Graph PowerShell — configure Entra and M365.
• PnP PowerShell — SharePoint provisioning.
• Custom scripts — invoke any API.

A single workflow can deploy across the full estate, not just the Power Platform solution.

Compare to Azure DevOps.

| Aspect | Azure DevOps | GitHub Actions | |---|---|---| | Microsoft official actions | ✓ (Build Tools) | ✓ (powerplatform-actions) | | OIDC support | ✓ | ✓ (newer, simpler) | | Approval gates | ✓ (rich) | ✓ (good) | | Marketplace breadth | Good | Largest | | Cost | Per-user | Per-minute | | Tight Microsoft ecosystem | More legacy ties | More modern |

Both work; GitHub Actions is the choice for new projects in most organisations.

Operational reality. Like any CI/CD, GitHub Actions for Power Platform pays back over time. Invest a week in setting it up; reap the benefits across every deployment from then on.