2.5 Power Platform Pipelines & CI/CD with Power Platform Build Tools
Key Takeaways
- Power Platform Pipelines lets makers self-serve solution promotion through admin-configured stages directly from the maker portal.
- Pipelines can be extended with pre-deployment and post-deployment steps, including calling a Power Automate flow at those points.
- Power Platform Build Tools' Unpack Solution task converts a solution zip into individually source-controllable, diffable files for git and code review.
- CI/CD service connections should authenticate as a least-privilege application user backed by a service principal, never a named developer's credentials.
- The Deploy Package task runs a compiled .NET package for advanced, code-driven deployment logic beyond standard import/export tasks.
Power Platform Pipelines & CI/CD with Power Platform Build Tools
Quick Answer: Power Platform Pipelines is the low-code, in-product way to promote managed solutions through admin-configured stages from the maker portal, extensible with pre- and post-deployment steps. Power Platform Build Tools is the pro-code way, wrapping pac operations as Azure DevOps or GitHub Actions tasks, with Unpack/Pack Solution enabling git-based source control.
Two Ways to Automate Deployment
This chapter's domain tests two complementary approaches to moving managed solutions through dev, test, and production without manual, error-prone maker-portal exports: the low-code, built-in Power Platform Pipelines, and the pro-code, external Power Platform Build Tools for Azure DevOps and GitHub Actions.
Power Platform Pipelines
Power Platform Pipelines is a first-party, in-product deployment tool. An admin configures a host environment, where the Pipelines app and configuration live, and a set of target environments representing stages such as Development, Test, and Production. Makers then deploy their own solutions through those stages directly from the maker portal, without needing Azure DevOps or admin intervention for every release.
- Each pipeline defines an ordered list of stages; a maker with the right permission triggers a deployment run that exports the solution as managed and imports it into the next stage's target environment.
- Run history is retained per pipeline so a developer can see what was deployed, when, by whom, and whether it succeeded - useful for both auditing and troubleshooting a bad release.
- Pipelines are extensible: a developer can attach pre-deployment and post-deployment steps, including calling a Power Automate flow at those extension points, to run validation, notify a team, or kick off automated tests before or after a stage promotion. This extensibility is what turns the low-code pipeline into a real release-gate mechanism.
- Because Pipelines runs inside the Power Platform itself, it's the right recommendation when the requirement is to let citizen developers and pro developers both promote solutions safely without standing up separate DevOps infrastructure.
Power Platform Build Tools (Azure DevOps / GitHub Actions)
For teams already using Azure DevOps or GitHub Actions, the Power Platform Build Tools extension supplies reusable pipeline tasks that wrap the same underlying operations the pac CLI exposes.
| Task | Purpose |
|---|---|
| Export Solution | Exports a solution, managed or unmanaged, from a source environment |
| Unpack Solution | Expands the exported zip into individual XML/YAML files suitable for source control - diffable, mergeable |
| Pack Solution | Reverses Unpack; rebuilds the deployable zip from source-controlled files, typically as managed for a release build |
| Import Solution | Imports a packed solution into a target environment |
| Set Solution Version | Bumps the solution version as part of a build, keeping versioning automated and consistent |
| Publish Customizations | Publishes all customizations in the target environment after import |
| Deploy Package | Runs a custom deployment package - a compiled .NET package - for advanced, code-driven deployment logic |
| Who Am I | Validates the pipeline's service connection can authenticate, useful as an early pipeline health check |
The unpack/pack pair is the crux of pro-code ALM: it converts a solution from an opaque zip into a folder of individual files that can be committed to git, code-reviewed through a pull request, and diffed component by component - exactly the workflow PL-400 expects a professional developer to use instead of manually exporting zips.
Authentication for CI/CD
Both approaches should authenticate as an application user backed by a service principal or Microsoft Entra app registration, with a Dataverse security role scoped to least privilege, never as a named developer's interactive credentials, which break the pipeline the moment that person's password rotates or they leave the team. The pac CLI itself supports this pattern locally through pac auth create --applicationId --clientSecret --tenant, mirroring how the DevOps or GitHub service connection authenticates.
Choosing Between Them
- Use Power Platform Pipelines when the priority is empowering makers and developers to self-serve promotions with minimal setup and native run history, and the organization doesn't already run Azure DevOps for this workload.
- Use Power Platform Build Tools when the solution needs source control, code review, automated testing, or integration with a broader software CI/CD process the organization already runs outside the Power Platform.
- The two are not mutually exclusive. Some teams unpack, pack, and source-control with Build Tools while still using Pipelines' run history and stage gates for the actual promotion, or trigger a pipeline's post-deployment Power Automate step from a Build Tools release.
Exam Angle
Expect PL-400 to test whether you can recommend the right mechanism for a stated constraint - source control required means Build Tools with unpack/pack; maker self-service without DevOps means Pipelines; needing to gate a promotion on an automated check means pipeline extensibility with a pre- or post-deployment flow - and whether the deployment identity follows least privilege through an application user.
A team wants pull-request code review and a diffable git history for every Dataverse solution change before it's deployed. Which Power Platform Build Tools task makes a solution's components individually diffable in source control?
An admin wants makers to promote their own solutions from Development to Test to Production directly from the maker portal, with built-in run history, and without standing up Azure DevOps. Which capability best fits this requirement?