How to create SDLC workflows using GitHub actions for Power Platform

In this video, we will learn about how to automate application lifecycle management using GitHub Actions for Power Platform.

The presenter Pierce Boggan guides us what collaboration, source control and Continuous Integration and Delivery (CICD) looks like with the Power Platform in GitHub.

At 00:17, he shows a Power App that his team has been building to track time off requests. Here on the app, we can see the current leave requests, their status, leave balance and company holidays. There is a pending and approval states for the requests but not ‘declined’.

We can edit this app in production and republish the changes but it is likely that we are going to want some traceability for these changes and have them tested before deploying them into production. This is the one main advantage of GitHub. So, we will use GitHub to see what it might look like to work through this entire workflow i.e., requesting this feature to actually building it with Power Platform to deploying it into production with GitHub actions.

From 01:00, he goes to GitHub to see for the repository for the Timeoff app. After giving the introduction about GitHub repositories, he shows us how to create a feature request. He navigates to the issues tab in GitHub, creates a new issue named ‘Add ‘Declined’ filter capability’.

After creating it, he submits this new issue and assigns a person to this issue. On this new issue page, we can then add comments and collaborate with other team members. We can also add milestones, labels and other these kind of things to the issue tab. This is a simple way to collaborating with other in the GitHub. Once we have created this issue, the developer building this app sees this issue and creates a fix for this issue.

At 02:40, Boggan goes to the Power Apps to fix this issue shows us what it looks like when we wire that to CICD with GitHub actions. He opens the Timeoff request ‘solutions’ and adds a leave request to this solution. What we are actually going to go to do with GitHub is we will represent this solution in source control.

He has also created different environments in there. The development environment, where he is currently making the changes to the app, the build environment, for testing the changes he’s made and then the production environment, where the app actually lives and interacts with end users.

From 03:40, he starts to update the leave request app. He simply goes to the studio and in the formula bar, adds the ‘filter declined’. The UI updates and we have the declined filter present on screen. He then saves and publishes the change. He again comes back to the ‘solutions’, refreshes the window and we can see that some 13 seconds ago, the leave-request app was modified.

So, we will now take this to source control and will create a new branch with these changes in GitHub. As we already know that a branch is just a different version of main folder that can make changes to the changes. He then hopes to GitHub and navigates to the action tab there.

These actions are workflow that we want to do inside the GitHub. So, based on something that happens in this folder, we may want to trigger some action. Then in our specific case, we may want to trigger the ability to go and get the latest solution from the Power Platform environment and bring that into the GitHub.

Form 05:09, Boggan goes over to the actions tab and selects the ‘export-and-branch’ solution. He also takes a look on the workflow file. The main thing about GitHub actions feature is that we don’t have to do anything. The only thing we have to do is specifying some property.

For example, our environment URL or our username and our solution name. After clicking on the ‘export-branch’, we are going to run this workflow and we can see that exporting branch workflow solution is now showing as queued.

We will then click on ‘export-from-dev’ and our workflow is going to start and run through a series of actions. This is going to take our solution from the Power Platform, bring that into GitHub by creating a new branch, put those changes in that branch and we will be able to track all the changes that are making to that solution inside of that development branch, without affecting the production folder we had, which was the main folder inside of GitHub.

At 06:50, after completing the GitHub action, he returns to the code view which should be unchanged till now. And this is because we were exporting to a branch. So, now when we click on these branches button, we see ‘time-off request’. After clicking on this, we can see the most recent change was some seconds ago.

We can also come into ‘commits’ and can see all the changes that were made. The great thing about putting this in source control is we can always trace back to any particular change that we have made.

Boggan then creates a pull request which is a request to pull the changes that are in one branch, into the main branch for production. So, our targeted issue has been fixed. We have merged the changes and if we go back to our code, we will see the latest change was a minute ago.

From 08:17, he deploys this change to production and creates a release of this change on GitHub. After creating it, he then publishes the release. So, our released solution to production, GitHub action has completed. We can then go to the production environment; refresh it and we can see the last modification of some 31 seconds ago.

At 10:12, Boggan runs the application that we have made changes to. He Logins as an employee and we can clearly see a ‘Decline’ filter there on the leave requests tab of the application. That is what we intended to do. What we have done here is we have seen the power of GitHub and the Power Platform together.

In this process, first of all, we represented that Power Platform solution that contained our app, as a repository in GitHub. This gave us traceability for the changes we were making with change tracking. Next, we logged an issue with our GitHub-issues for the app developer. After that, the app developer made the changes in development power platform without production affecting production users, represented those changes in branching GitHub using Actions. We then tested those changes and deployed them into production using another GitHub action.

So, this shows us how easy it is to deliver application lifecycle management. Traceability would change tracking and CICD with Power Platform in GitHub.