Implement Power Platform CI/CD with Azure DevOps

TL;DR

• A solution ZIP ≠ everything: it carries tables/apps/flows, but env vars are placeholders and connection references must be rebound in each target environment.

• Use Azure DevOps with service connections per environment, Key Vault for secrets, and parameterized variables to avoid hard-coding.

• Pipeline shape: Export → Artifact → Import (managed) → Set env vars → Map connections → Smoke tests → Notify → Rollback if needed.

• Add monitoring & feedback loops so each release gets safer and faster.

What’s actually in (and out of) a solution

• In: Dataverse tables/columns, model-driven & canvas apps, flows, BPFs, plugins, web resources.

• Placeholders: Environment variables (must be set per environment).

• Pointers: Connection references (must be mapped to real connections in target).

• Not included: Secrets/credentials, environment-specific endpoints/IDs, and reference/lookup data (migrate with Configuration Migration).

Required Azure DevOps building blocks

• Service connections (Power Platform): Scoped to each target environment with least privilege.

• Variable groups: Store per-env URLs, IDs, feature flags; link to Azure Key Vault for secrets (client secret/SP password).

• Artifacts: Keep every exported/released solution for rollbacks.

• Approvals & gates: Manual checks or automated policies before prod.

Reference pipeline blueprint (stages)

1. Build

   • Export unmanaged from DEV.

   • (Optional) Convert/export managed for higher envs.

   • Run Solution Checker.

2. Package

   • Publish solution ZIP as artifact; version/tag.

3. Deploy to TEST/PROD

   • Import managed solution.

   • Set environment variables (per-env values).

   • Map connection references to target connections.

   • Run smoke tests (trigger a key Flow; open app; validate API ping).

   • Notify via Teams/Email; fail fast on errors.

4. Post-deploy

   • Enable schedules; warm up; monitor telemetry.

   • Provide one-click rollback to last good artifact if smoke fails.

Variable & secret strategy

• Parameters: environment, targetEnvUrl, solutionName, connectionRefNames[].

• Variable groups per env: ApiBaseUrl, TenantId, DataverseUrl, flags.

• Key Vault: ServicePrincipalSecret, 3rd-party API keys; rotate without YAML edits.

Connection reference mapping (must-do)

• After import, bind each solution Connection Reference to a Connection that exists in the target environment.

• Automate with Power Platform CLI/PowerShell scripts (PAC/PowerApps Admin) using env-scoped variables.

Data & config migration

• Ship reference/lookup data with Configuration Migration Tool or Package Deployer.

• Order: parent → child tables. Validate row counts and lookups post-load.

Smoke tests that matter

• Trigger critical Flow with synthetic payload; assert success & outputs.

• Create/update a test Dataverse record and verify BPF/Plugin fired.

• Canary API call to environment-specific endpoint; check 200 + expected shape.

Rollback & recovery

• Keep previous managed ZIP as artifact; pipeline task re-imports last known good on failure.

• Disable schedules before rollback; re-enable after validation.

Minimal YAML skeleton (concept)

• Parameters: env, solutionName

• Variables: group per env; Key Vault secrets

• Tasks: Export → Publish → Import (managed) → Set Env Vars (script) → Map Connections (script) → Smoke Test (script) → Notify

Pre-flight checklist

• ✅ Solution Checker: no criticals.

• ✅ Env variables documented and values present for target.

• ✅ Target connections exist; service connection authorized.

• ✅ Reference data package ready.

• ✅ Rollback artifact available.

• ✅ Maintenance window/approvals set (prod).

Anti-patterns to avoid

• Hard-coding URLs/secrets in YAML or flows.

• Skipping connection mapping (“it worked in dev”).

• Unmanaged imports to prod; no rollback plan.

• Manual edits after deploy (drift).

• One giant solution with “Add Existing everything” and no layering.

Quick wins (this week)

• Create variable groups per environment and link Key Vault.

• Add connection-mapping & env-var scripts to your pipeline.

• Store solution ZIPs as versioned artifacts; script rollback.

• Add one smoke test that touches your most critical Flow.

FAQ

Do I need separate pipelines for TEST and PROD?
One multi-stage pipeline is fine—gate with approvals, variable groups, and protected branches.

Can I avoid manual connection setup forever?
You can automate binding, but the underlying connections must exist in each environment (created once, then referenced).

Managed or unmanaged to higher envs?
Use managed for TEST/PROD for clean layering, uninstallability, and predictable upgrades.