name: alm description: "Application Lifecycle Management for Power Platform. Use when: setting up CI/CD pipelines, GitHub Actions, solution deployment, environment variables, connection references, managed solutions, Power Platform Pipelines, pac solution sync, deployment settings."

Skill: Application Lifecycle Management (ALM)

When to Use

Trigger when designing deployment pipelines, managing solutions, promoting across environments, or setting up CI/CD for Power Platform.

ALM Golden Rules

1. Never import unmanaged solutions to Test or Production
2. Every environment needs a dedicated service principal — no human accounts in pipelines
3. Environment variables must be set per environment — never hardcoded
4. Connection references must be pre-created before solution import
5. Solution version must increment on every build (major.minor.build.revision)
6. Always run Solution Checker before promoting to Test/Prod

⚠️ REQUIRED: Load Sub-Files Before Implementation

SKILL.md is a summary only — it is NOT sufficient for implementation.

The detailed content (complete payloads, XML templates, working examples, edge-case handling) lives in sub-files in the same directory as this SKILL.md. Before writing any code, you MUST use read_file on the sub-files relevant to your task:

• Developer Inner Loop — Three development loops (Web API direct, pac code push, pac solution sync), when to use each, day-to-day workflows
• Git Integration — Native Git integration in maker portal, deploy from Git (2026 wave 1), branch strategies for Power Platform, Azure DevOps Boards integration
• Azure DevOps Pipelines — ADO pipeline YAML templates, service connections, multi-stage deployment, variable groups

Solution Lifecycle

Developer writes code / configures in Dev (unmanaged)
  ↓
Export solution from Dev → Unpack to source control
  ↓
CI pipeline: Pack → Solution Checker → Build managed artifact
  ↓
CD pipeline: Import managed solution to Test → Smoke test
  ↓
CD pipeline: Import managed solution to UAT → User acceptance
  ↓
CD pipeline: Import managed solution to Production → Go live

Code Apps ALM

Development Workflow

# Local development (no environment needed for initial dev)
npx degit microsoft/PowerAppsCodeApps/templates/starter my-app
cd my-app && npm install
npm run dev                    # http://localhost:5173

# Connect to Power Platform
pac code init --displayname "My App"
pac code add-data-source -a dataverse -t contact

# Deploy to Dev environment
npm run build
pac code push                                     # Preferred solution
pac code push --solutionName "ContosoCodeApp"     # Named solution

Code Apps ALM Strategy

1. Source control: Standard Git workflow on the web app source code
2. Solution packaging: Use pac code push to deploy into a Dataverse solution
3. Environment promotion: Once in a solution, use Power Platform Pipelines or CI/CD
4. No Solution Packager: Code Apps cannot be decomposed like traditional components — manage via Git on the source, not on the solution XML

CI/CD for Code Apps (GitHub Actions)

name: Code App Build & Deploy

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install dependencies
        run: npm ci

      - name: Build
        run: npm run build

      - name: Install PAC CLI
        uses: microsoft/powerplatform-actions/actions-install@v1

      - name: Authenticate
        run: |
          pac auth create \
            --url ${{ secrets.DEV_ENV_URL }} \
            --applicationId ${{ secrets.CLIENT_ID }} \
            --clientSecret ${{ secrets.CLIENT_SECRET }} \
            --tenant ${{ secrets.TENANT_ID }}

      - name: Deploy Code App
        run: pac code push --solutionName ${{ vars.SOLUTION_NAME }}

Traditional Solution ALM

Branch Strategy

main              ← Production-ready, protected
  └── release/v1.x  ← Release candidate, deploys to Test → UAT → Prod
        └── feature/PP-123-description  ← Dev work, deploys to Dev env

Solution Export & Unpack

# Export unmanaged from Dev
pac solution export --name MySolution --path ./out --managed false --overwrite true

# Unpack for source control
pac solution unpack \
  --zipfile ./out/MySolution.zip \
  --folder ./src/MySolution \
  --processCanvasApps true \
  --allowDelete true

# Commit to Git
git add src/MySolution/
git commit -m "chore: export MySolution from dev"

Solution Pack & Import

# Pack managed solution from source
pac solution pack \
  --zipfile ./out/MySolution_managed.zip \
  --folder ./src/MySolution \
  --type Managed

# Import to target environment
pac solution import \
  --path ./out/MySolution_managed.zip \
  --async true \
  --activate-plugins true \
  --publish-changes true

Environment Variables

Definition (in solution XML)

<environmentvariabledefinition>
  <schemaname>contoso_ApiBaseUrl</schemaname>
  <displayname>API Base URL</displayname>
  <type>String</type>
  <!-- No defaultvalue in managed solution — set per environment -->
</environmentvariabledefinition>

Setting per Environment

pac env update-settings \
  --environment $TARGET_ENV_URL \
  --setting contoso_ApiBaseUrl=https://api.contoso.com

Accessing in Canvas App

Set(
    gblApiBaseUrl,
    LookUp(
        'Environment Variable Values',
        'Environment Variable Definition'.'Schema Name' = "contoso_ApiBaseUrl",
        Value
    )
);

Connection References

Purpose: Abstract connections so solutions can be deployed across environments without breaking.

Rules:

• Every flow must use connection references (never direct connections)
• Connection references are pre-created in each target environment
• Use service principal connections in test/prod (not personal accounts)
• Document required connection references in deployment checklist

Deployment Checklist

## Deployment: [Solution] v[Version] → [Environment]

### Pre-Deploy
- [ ] Solution Checker: 0 critical, <5 high findings
- [ ] Version incremented from last deployment
- [ ] Environment variables documented for target environment
- [ ] Connection references pre-created in target environment
- [ ] Service principal has System Administrator in target environment
- [ ] Environment backup taken (for rollback)

### Deploy
- [ ] Import managed solution (async mode for large solutions)
- [ ] Monitor import job to completion
- [ ] Publish all customizations

### Post-Deploy
- [ ] Smoke test key user scenarios
- [ ] Verify flows are turned on (import can turn them off)
- [ ] Verify environment variable values are correct
- [ ] Confirm plugin steps are active
- [ ] Tag release: git tag v[version]-[environment]

### Rollback Plan
- [ ] Previous version of managed solution available as artifact
- [ ] Rollback: import previous version (managed upgrade)
- [ ] Verify rollback doesn't cause data loss (schema changes are one-way)

GitHub Actions — Full CI/CD Pipeline

name: Power Platform CI/CD

on:
  push:
    branches: [release/**]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: microsoft/powerplatform-actions/actions-install@v1

      - name: Pack Managed Solution
        uses: microsoft/powerplatform-actions/pack-solution@v1
        with:
          solution-folder: src/MySolution
          solution-file: out/MySolution_managed.zip
          solution-type: Managed

      - name: Solution Checker
        uses: microsoft/powerplatform-actions/check-solution@v1
        with:
          environment-url: ${{ secrets.DEV_ENV_URL }}
          app-id: ${{ secrets.CLIENT_ID }}
          client-secret: ${{ secrets.CLIENT_SECRET }}
          tenant-id: ${{ secrets.TENANT_ID }}
          path: out/MySolution_managed.zip

      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: managed-solution
          path: out/MySolution_managed.zip

  deploy-test:
    needs: build
    runs-on: ubuntu-latest
    environment: test
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: managed-solution

      - uses: microsoft/powerplatform-actions/actions-install@v1

      - name: Import to Test
        uses: microsoft/powerplatform-actions/import-solution@v1
        with:
          environment-url: ${{ secrets.TEST_ENV_URL }}
          app-id: ${{ secrets.CLIENT_ID }}
          client-secret: ${{ secrets.CLIENT_SECRET }}
          tenant-id: ${{ secrets.TENANT_ID }}
          solution-file: MySolution_managed.zip
          force-overwrite: true
          publish-changes: true
          run-asynchronously: true
          activate-plugins: true

  deploy-prod:
    needs: deploy-test
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: managed-solution

      - uses: microsoft/powerplatform-actions/actions-install@v1

      - name: Import to Production
        uses: microsoft/powerplatform-actions/import-solution@v1
        with:
          environment-url: ${{ secrets.PROD_ENV_URL }}
          app-id: ${{ secrets.CLIENT_ID }}
          client-secret: ${{ secrets.CLIENT_SECRET }}
          tenant-id: ${{ secrets.TENANT_ID }}
          solution-file: MySolution_managed.zip
          force-overwrite: true
          publish-changes: true
          run-asynchronously: true
          activate-plugins: true

Power Platform Pipelines (First-Party ALM)

Power Platform Pipelines is Microsoft's in-product ALM solution — the strategic alternative to GitHub Actions for maker-led deployments.

When to Use

Both GitHub Actions and Azure DevOps Pipelines use PAC CLI commands under the hood. The pipeline YAML syntax differs but the Power Platform operations are identical. See ado-pipelines.md for Azure DevOps templates.

Key Features

• In-product: deploy directly from Power Apps / Power Automate Studio
• Service principal supported — no human accounts in pipelines
• Service principal configurable per pipeline/stage — different SPN for test vs prod
• Pre/post-deployment steps for business process validation
• Delegated deployments with approval workflows — makers submit, admins approve
• Centrally managed by admins via Power Platform Admin Center
• Automatically handles connection references and environment variables
• Included in Managed Environments (no extra licensing)
• Cross-geo deployments supported (when enabled in host)
• Rollback capability: redeploy previous solution versions from pipeline history
• Solution backups automatically stored for every deployment
• Extensibility hooks for custom pre/post-deployment logic
• Default import behavior: Upgrade without Overwrite customizations

IMPORTANT (Feb 2026): Pipeline target environments must be Managed Environments. Starting February 2026, Managed Environments are auto-enabled on pipeline targets. Environments that are not Managed Environments cannot be used as deployment targets.

Setup

1. Create a "host environment" (dedicated environment for pipeline management)
2. Install "Power Platform Pipelines" app in the host environment
3. Configure pipeline: Dev → Test → Production
4. Grant makers access to run the pipeline
5. Makers deploy from the app: Deploy → Select Solution → Run Pipeline

Deployment Settings File

Automate connection reference and environment variable configuration during solution import (CI/CD pipelines).

Generate the File

# Generate from an existing solution zip
pac solution create-settings \
  --solution-zip ./out/MySolution_managed.zip \
  --settings-file ./config/deployment-settings.json

File Structure

{
  "EnvironmentVariables": [
    {
      "SchemaName": "contoso_ApiBaseUrl",
      "Value": "https://api.contoso.com"
    },
    {
      "SchemaName": "contoso_FeatureFlag",
      "Value": "true"
    }
  ],
  "ConnectionReferences": [
    {
      "LogicalName": "contoso_SharedOutlook",
      "ConnectionId": "shared-outlook-connection-guid",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365"
    }
  ]
}

Using in GitHub Actions

- name: Import to Test
  uses: microsoft/powerplatform-actions/import-solution@v1
  with:
    environment-url: ${{ secrets.TEST_ENV_URL }}
    app-id: ${{ secrets.CLIENT_ID }}
    client-secret: ${{ secrets.CLIENT_SECRET }}
    tenant-id: ${{ secrets.TENANT_ID }}
    solution-file: MySolution_managed.zip
    use-deployment-settings-file: true
    deployment-settings-file: ./config/deployment-settings-test.json
    force-overwrite: true
    publish-changes: true
    run-asynchronously: true

Security note: Never commit environment variable values with secrets to Git. Use per-environment settings files stored outside source control or populated at runtime via pipeline secrets.

pac solution sync

Syncs the local solution project directory to the current state of the solution in your Dataverse environment. Useful for keeping source control in sync after in-environment changes.

# Sync local folder to current state of solution in connected environment
pac solution sync

# With options
pac solution sync \
  --async \                    # Export asynchronously
  --localize \                 # Extract/merge .resx string resources
  --packagetype Both           # Unmanaged + Managed

Typical workflow:

# Maker makes changes in Dev environment UI
# Developer syncs changes back to source control
pac solution sync
git add src/MySolution/
git commit -m "feat: add priority field to order table"

Managed Environments

Managed Environments is a suite of premium governance capabilities included with Power Apps Premium, Power Automate Premium, Dynamics 365, and Copilot Studio licenses.

Key Capabilities

Enable Managed Environments

Power Platform Admin Center → Environment → Edit → Enable Managed Environments

Solution Layering & Conflict Resolution

Dataverse uses a layering system to resolve conflicts when multiple solutions modify the same component (e.g., two solutions both customize the Contact form).

Layer Hierarchy (top wins)

Active customizations (unmanaged — dev environment only)
  ↑ overrides
Managed solution B (imported later)
  ↑ overrides
Managed solution A (imported first)
  ↑ overrides
System defaults (out-of-box)

Common Conflict Scenarios

Diagnosing Active Layer Issues

# Check solution layers for a specific component
pac solution check --path ./out/MySolution_managed.zip

# In the Power Platform admin center:
# Environment → Solutions → Select component → See solution layers
# This shows which solution "owns" each property of a component

Multi-Team Coordination

• One solution per team — avoid multiple teams editing the same solution
• Layered solutions — shared tables in base solution, team-specific apps in separate solutions
• Use pac solution sync before each export to detect environment drift
• Review solution XML diffs in Git before committing

Anti-Patterns

• Importing unmanaged solutions to production
• Developers with System Administrator in test/prod
• Flows using personal connections (must use connection references)
• Skipping Solution Checker before environment promotion
• Missing --processCanvasApps true on solution unpack (binary .msapp in source control)
• Environment-specific GUIDs committed to solution XML
• No version increment between deployments
• No rollback plan documented
• Using Power Platform Pipelines AND GitHub Actions for the same solution (pick one)
• Storing secret environment variable values in deployment settings files committed to Git

Related Skills

• architecture — Solution structure and environment topology decisions
• code-apps — Code Apps build and deploy workflow
• plugins — Plugin assembly deployment in managed solutions