CI/CD Pipelines for Power Platform
Stop deploying manually. Learn how to automate solution deployment with Power Platform Pipelines, Azure DevOps Build Tools, and GitHub Actions — from export to production in one click.
Why automate deployment?
Imagine a pizza shop where orders are delivered by hand.
The chef makes the pizza, walks to the delivery van, drives to the customer, walks back, and starts the next pizza. Slow, error-prone, and the chef cannot focus on cooking.
Now imagine a conveyor belt system: the chef puts the pizza on the belt, it moves to quality check, then packaging, then delivery. The chef focuses on cooking while the belt handles logistics.
CI/CD pipelines are the conveyor belt for your Power Platform solutions. You commit your changes, and the pipeline automatically exports, tests, and deploys them through dev → test → production. No manual steps, no forgotten configurations, no “it worked on my machine.”
Two approaches to CI/CD
| Feature | Power Platform Pipelines (Native) | Build Tools for Azure DevOps / Power Platform Actions for GitHub |
|---|---|---|
| Setup complexity | Low — configure in admin centre | Medium — requires YAML pipeline definition |
| Target audience | Admins, citizen developers | Pro developers, DevOps engineers |
| Customisation | Limited — predefined stages | Full — any task in the pipeline |
| Pre-deployment checks | Solution checker (built-in) | Solution checker + custom tests + any tool |
| Approval gates | Built-in approval workflow | Azure DevOps approvals or GitHub environment protection rules |
| Source control | No — solution stays in Dataverse | Yes — solution unpacked to Git repo |
| Rollback | Manual (reimport previous version) | Automated (Git revert + redeploy) |
| Best for | Simple deployments, small teams | Enterprise ALM, multi-team, complex workflows |
Power Platform Pipelines
Native pipelines let you deploy solutions through stages without leaving the Power Platform admin centre.
How they work
- Define stages — Map environments to pipeline stages (Dev → Test → Prod)
- Deploy — Select a solution, choose the target stage, click Deploy
- Approval — If configured, the deployment waits for approval before proceeding
- Validation — Solution checker runs automatically to catch issues
Extending pipelines
You can extend native pipelines with:
- Pre-deployment and post-deployment hooks — cloud flows that run before or after deployment
- Custom stages — add intermediate environments (e.g., UAT between Test and Prod)
- Approval workflows — require specific users or groups to approve before deployment proceeds
Scenario: Elena sets up pipelines at Meridian Healthcare
Elena Vasquez configures Power Platform Pipelines for Meridian Healthcare’s claims solution:
- Stage 1: Development →
meridian-devenvironment (Kai builds here) - Stage 2: Test →
meridian-test(QA team validates) - Stage 3: Production →
meridian-prod(live system) - Approval: Test → Prod requires Elena’s approval
- Pre-deployment hook: A cloud flow backs up the current production solution before deployment
- Post-deployment hook: A flow sends a Teams notification to the IT support channel
This gives the team a one-click deployment with safety checks built in.
Power Platform Build Tools
For teams that need full CI/CD control, Build Tools integrate Power Platform with Azure DevOps pipelines or GitHub Actions.
Key tasks/actions
| Task | What It Does |
|---|---|
| Who Am I | Verify connection to the environment |
| Export Solution | Export a solution (managed or unmanaged) from source environment |
| Unpack Solution | Extract solution into individual files for source control |
| Pack Solution | Repackage individual files into a solution ZIP |
| Import Solution | Import solution into target environment |
| Publish Customizations | Publish all pending customisations in the target environment |
| Solution Checker | Run static analysis on the solution for best practice violations |
| Set Solution Version | Update the solution version number (supports SemVer) |
| Delete Solution | Remove a solution from an environment |
A typical CI/CD pipeline
Developer workflow (source control):
1. pac auth create --environment dev-url
2. pac solution export --path solution.zip (UNMANAGED — the working copy)
3. pac solution unpack --zipfile solution.zip --folder ./src
4. Commit unpacked solution to Git (source of truth)
5. Push to main branch
CI (Build pipeline — triggered by push):
6. pac solution pack --folder ./src --zipfile managed.zip --type Managed
7. Run solution checker on managed.zip
8. Publish managed.zip as a pipeline artifact
CD (Deploy to Test):
9. pac auth create --environment test-url
10. pac solution import --path managed.zip --activate-plugins
11. Run integration tests
CD (Deploy to Prod — after approval):
12. pac auth create --environment prod-url
13. pac solution import --path managed.zip --activate-plugins
14. pac solution publishExam tip: pac CLI commands for CI/CD
The exam expects you to know the pac CLI commands used in CI/CD pipelines:
pac solution export→ exports from an environmentpac solution import→ imports to an environmentpac solution unpack→ extracts to source-controllable filespac solution pack→ creates a ZIP from unpacked filespac solution check→ runs solution checkerpac auth create→ authenticates to an environment using service principal
Service principal authentication (--applicationId, --clientSecret, --tenant) is used in pipelines because they run unattended — no user to sign in interactively.
Elena's team uses Azure DevOps to deploy solutions. A developer pushes changes to the main branch. The pipeline exports the solution from dev, runs solution checker, and imports into test. But the import fails with 'missing dependency' on a table from another solution. What should Elena do to prevent this?
🎬 Video coming soon
Next up: Advanced Power Fx & Canvas Components — writing complex formulas, building component libraries, and integrating Power Automate from canvas apps.