Power Platform ALM with Azure DevOps

For Power Platform teams that take application lifecycle management seriously, the canonical CI/CD path runs through Azure DevOps (or its sibling GitHub Actions). The Microsoft-published Power Platform Build Tools extension supplies the building blocks; the rest is pipeline composition.

Power Platform Build Tools. A free Azure DevOps extension Microsoft maintains. It provides tasks for:

• Authenticate — service-principal sign-in to a Power Platform environment.
• Tool installer — install / cache the pac CLI.
• Pack / unpack solution — convert between solution.zip and unpacked source files.
• Import / export solution — pull from or push to an environment.
• Publish customisations — make changes effective after import.
• Apply / unpack solution upgrade — managed solution upgrade flow.
• Solution checker — static analysis against Microsoft's published rules.
• Set solution version — update version in metadata before packaging.
• Reset environment — wipe and restart a sandbox.

These tasks compose into pipelines covering build, validation, and deployment.

Typical pipeline structure.

# Build pipeline (runs on PR or main commit)
- Checkout source from Git
- Pack solution from unpacked source folder
- Run solution checker against the packed solution
- Publish artefact: the .zip

# Release pipeline (deploys to environments)
- Stage 1: Deploy to UAT
  - Import managed solution to UAT environment
  - Run smoke tests (Power Automate or custom)
  - Manual approval gate

- Stage 2: Deploy to Production
  - Import managed solution to Production environment
  - Publish customisations
  - Notify stakeholders

Source control structure. A typical repo:

src/
  Solution.Customer/
    Other/ (solution.xml, customizations.xml)
    Entities/ (per-table folders with metadata)
    Workflows/
    Reports/
    Plugins/
    WebResources/
    PluginAssemblies/
build/
  build.yml
  release.yml

pac solution unpack extracts a solution.zip into this folder structure for source control; pac solution pack converts back to a .zip for deployment.

Service principals. Pipelines authenticate to Power Platform environments as service principals registered in Microsoft Entra ID. Each environment trusts a service principal with appropriate permissions (System Administrator role on the target Dataverse environment). Storing credentials in Azure DevOps secret variables (or Azure Key Vault for higher security) keeps them out of source.

Solution checker integration. A best practice is to gate every PR build on solution checker results. The checker scans for performance issues, security concerns, accessibility problems, and platform misuse. Failing the build on critical issues forces fixes before merge.

Environment variables. Solutions can contain environment variables that hold values differing per environment — API URLs, connection identifiers, feature flags. The pipeline injects the correct values per target environment at import time.

Connection references. Power Automate flows depend on connection references that abstract the specific connection used. The pipeline maps connection references to actual connections per environment, so a flow that calls SharePoint in dev hits the dev SharePoint, and in production hits production SharePoint.

Approval gates. Production deployments should require manual approval — typically a release manager or governance team signing off. Azure DevOps supports approvals with deferral, audit, and Teams integration.

Telemetry and rollback. Capture deployment success / failure events to Application Insights. Configure rollback as a separate pipeline that imports the previous solution version. Test the rollback occasionally.

Operational reality. Teams that adopt Power Platform ALM with Azure DevOps deploy more confidently and recover from issues faster. The initial investment — pipeline build, training, source-control migration of existing solutions — takes a week or two; the ongoing pay-off compounds over years.