Azure DevOps and GitHub Actions for Power Platform ALM
Power PlatformAzureALM

Azure DevOps and GitHub Actions for Power Platform ALM (10/15)

External CI/CD is powerful, and it is also a product in its own right. Before choosing Azure DevOps or GitHub Actions for Power Platform, I ask one question: who is going to own it on a bad day?

When external pipelines earn their place

Built-in Power Platform pipelines cover a lot. External CI/CD becomes worth it when you need things they do not do:

  • triggers from source control, such as a merged pull request;
  • custom tests or code builds, like plug-ins, PCF controls or scripts;
  • coordination across several repositories or systems;
  • infrastructure steps in Azure alongside the solution;
  • fitting into an engineering platform the organisation already runs.

If none of those apply, the extra moving parts probably cost more than they give back.

Design it so failures are easy to read

Split the pipeline into separate stages — build, validate, configure, import — so that when it fails, the stage name already tells you where to look.

Publish the exact managed artefact and the logs from every run. If you cannot reproduce a release from what the pipeline kept, you cannot really investigate it.

Identity and secrets

This is where I see the most shortcuts. A pipeline should authenticate as a service principal or managed identity designed for deployment, never as a person's account.

Keep secrets in the platform's secret store and keep deployment settings environment-specific. A pipeline with a maker's credentials in it is a production dependency nobody agreed to.

Who owns it

Runners, service connections, task versions, upgrades and failure handling all need an owner. If nobody has that job, the built-in pipeline may be the safer design, even if it is less flexible.

I favour external CI/CD when the organisation can operate it as a product. When it cannot, a simpler pipeline that people trust is better than a powerful one that nobody maintains.

A practical next step

Before choosing a tool, write down the minimum stages your release actually needs, and the identity each stage runs as. Then pick the simplest tool that covers that list.

Sources

References used for this article. Links open in a new tab.

  1. Microsoft Learn — Application lifecycle management (ALM) with Microsoft Power Platform
  2. Microsoft Learn — Set up pipelines in Power Platform
  3. Microsoft Learn — Pre-populate connection references and environment variables for automated deployments using Power Platform Build Tools
  4. Microsoft Learn — Git version control
  5. GitHub Pages — pipelines and source control (PDF)