Public Preview of GitHub Actions for Power Platform ALM

There is a new kid in town! Not long after the Power Apps Build Tools for Azure Dev Ops were released out of beta under the new name of Power Apps Build Tools (https://marketplace.visualstudio.com/items?itemName=microsoft-IsvExpTools.PowerPlatform-BuildTools) the new set of GitHub actions for Power Platform ALM have been released in public preview (https://powerapps.microsoft.com/en-us/blog/github-actions-for-the-power-platform-now-available-in-preview/). They can be used in your workflows today and will be available in the GitHub Marketplace later in the year.

Since Microsoft acquired GitHub for $7.5 Billion back in 2018 there has been a growing amount of investment – it seems that parity with Azure Dev Ops is inevitable before long. The CI/CD story in the open-source world has been served using products such as Octopus Deploy for a long time, but one of the investments Microsoft have made is in the are of GitHub actions (https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/)

GitHub Actions for Power Platform ALM

Actions and Workflows give a yaml build pipeline with a set of hosted build agents. This provides a significant step towards some degree of parity with Azure Pipelines.

With the public preview of the Power Platform GitHub actions, we can come some way to moving our CI/CD pipeline to GitHub. At this time, not all of the Azure Dev Ops Power Platform Build Tools are supported yet – with the most notable omission being the Solution Checker and environment management tasks.

Power Platform Build Tools

GitHub Power Platform Actions

WhoAmI

who-am-i

Power Platform Checker

---

Power Platform Import Solution

import-solution

Power Platform Export Solution

export-solution

Power Platform Unpack Solution

unpack-solution

Power Platform Pack Solution

pack-solution

Power Platform Publish Customizations

---

Power Platform Set Solution Version

---

Power Platform Deploy Package

---

Power Platform Create Environment

---

Power Platform Delete Environment

---

Power Platform Backup Environment

---

Power Platform Copy Environment

---

---

branch-solution

---

clone-solution


An interesting addition to the GitHub actions is the branch-solution action which I think is intended to be used when you want a new pro-code or low-code environment to match a GitHub branch so that you can ‘harvest’ the solution xml from any changes automatically. I look forwards to seeing documentation on the best practices surrounding this action.

There are two missing features that I would really like to see in the actions:

  1. Client Secret Authentication
  2. Cross-Platform Support

When do we move from Azure Dev Ops then?

Not yet! Personally, I feel the biggest gap in actions is the maturity around the release management in GitHub actions. Azure Dev Ops allows you to create multi-stage deployments with approval gates that can be driven from the output of a specific build, whereas GitHub actions require you to manage this using release tags and branch merging or external integrations.

Example

You can see an example of the new GitHub actions at work in my NetworkView PCF control repo (https://github.com/scottdurow/NetworkViewPCF)

Each time a pull request is merged into the master branch, the PCF control is built, the solution packaged and a release created.

Since the solution contains more than just the PCF control (forms too!), I have a folder called solution_package that contains the solution as unpacked by the Solution Packager. After the PCF control is built, a script is then used to copy the bundle.js into the solution package and update the version of the artefacts. Then the solution is built using the microsoft/powerplatform-actions/pack-solution@latest action. I chose to use a node script rather than PowerShell/PowerShell Core so that eventually it will be easier to be cross-platform once the Power Platform tools are also cross-platform.

You can take a look at the build yaml here - https://github.com/scottdurow/NetworkViewPCF/blob/dev/.github/workflows/build.yml 

@ScottDurow

Comments are closed