Publish Power Apps securely via GitHub (Part 1)

Settings in Azure Active directory (AAD) and Power Platform Admin Centre for GitHub

This article is Publish Power Apps securely via GitHub (part 1). You'll need to have completed it before setting up your Power App and GitHub repositories. This article deals with the rather tortuous path of settings in what used to be called Azure Active directory and Power Platform Admin Centre.

Why have Power Apps been extended to support GitHub? (a theory)

When it comes to publishing Power Apps for client environments things can get tricky quickly. To a devops oriented person, the idea of modifying unmanaged code in production and risking duplication of effort, mistakes and losing track of those modifications should be abhorrent. Although it might have seemed justifiable under pressure and while cutting teeth on one or two apps, it would quickly get out of hand and start a journey along a path to madness! Nevertheless anecdotally it seems that many enterprise Power Apps deployment environments are based on exactly these kinds of shaky foundations. What should be done about it?

Fortunately, Microsoft have started to think about Application Lifecycle Management (ALM) for Power Apps. Although I have no knowledge of the inner working of the company, it is as if a grown up Microsoft Corporate Vice President (CVP) has got the Microsoft Power Platform division executives in a room together and explained to them gently, so as not to dent their enthusiasm, that their dream of allowing apps to just sprout out of the minds of digital citizen makers and into production, ends up suffering from a lack of governance, which itself could easily result in criticism of the Power App due to weaknesses, bad design, or lack of scale. The Microsoft CVP might go on to explain with evidence and anecdotes dating back decades, that without successful reference deployments of brilliant apps, Power Platform and Power Apps won't achieve widespread adoption and thus are likely ultimately to fail or get bogged down in an organisation perhaps even tarnishing the overall Microsoft Power Platform brand.

And after a pause, the CVP might have gently reminded the audience that Microsoft bought GitHub for a reason, and that the Power Apps team ought to integrate with deeply so as to connect apps built by digital citizens from the maker community with the professional in-house IT Departments and their developers and partners worldwide so that  they can be properly managed, audited, and subject to rigour about releases to the point at which they are happy to help with the management of Power Platform and of bringing Power Apps to the mainstream.

So how nice it is then to find that my mythical CVP doesn't have to bang heads together because you can now use GitHub for Application Lifecycle Management (ALM) with Power Apps and though it is late to the party and quickly evolving this is very welcome and necessary to drive successful adoption.

What follows is the first part of a step by step implementation of strategy for publishing Power Apps via GitHub a simple Power App, This requires the creation of several Microsoft Dataverse environments in Power Apps Admin and the creation of a service principal with appropriate permissions in Azure Active Directory (AAD). This will allow for the creation of much better quality assured Power Apps because the deployment process will be managed automatically, securely, and with less room for human error.

Step by step guide to my settings in Azure Active directory (AAD) and Power Platform Admin Centre for GitHub

Environments

Best practice hierarchy: Microsoft recommend that you establish three Microsoft Dataverse environments in your tenant This is impossible to do without a paid licence for Power Apps which contains Dataverse (Common Data Service) capacity. If you have that then you should create, Sandbox, Staging, and then Production environments for your company and your clients. A sandbox environment is not for production, it is for testing of developers work integrated into a Power Platform app. All developers require environment maker access. Testers just require user access.

Developer Plan hierarchy: My Power Platform environment is using the Power Apps Developer Plan which gives you a free development environment to build and test with Power Apps, Power Automate, and Microsoft Dataverse. You can get a developer licence here. Unfortunately the Power Apps Developer Plan does not have enough environment capacity to be able to use the recommended Microsoft best practices to automate building and deploying your app using GitHub Actions for Power Platform but you can get started to prove it out by using the default environment.

Although it is a production environment, it is the place in your organisation where all licenced users have the environment maker role and can experiment with Power Apps. Such apps might be chosen for more active management but it is essentially a playground.

However, the Power Apps Developer Plan only has two environments, Developer and Default, so to create the ALM Build environment I had to use a 'Trial' environment which is only good for thirty days. It isn't perfect but it is FREE, and as I am the only user in my tenant the issues with the default environment do not arise. Follow the instructions in the tutorial here.

Create a trial environment

• Sign in to Power Platform admin centre
• Select Environments from the menu.
• Click "+ New" to create the trial environment.
• Name the environment "ALM - Trial" 
• Choose the region
• Choose the environment type "Trial"
• Select the "Create a database for this environment" toggle button
• Click "Next"
• Set your language
• Set your currency
• Select the "Deploy sample apps and data" toggle button
• Click "Save"

Review your environments before continuing

So now you should have three environments. The default environment, a developer environment and a trial environment. That is just enough to create separation between individual developer work, the build (trial) environment, and the 'production' (but default) environment. This seems over complex but it represents good practice.

Create an app registration with Azure Active Directory

The environments need to be accessed automatically by GitHub Actions, so there needs to be a way to authorise GitHub to connect to all three of the environments. This is done by registering each environment as an "application" with Azure Active Directory, which enables you to specify a client secret to identify and authorise GitHub Actions. Each application in Azure Active Directory is given the rights to read and write to the environments you have created and assigned as an app user for Power Apps for each environment. The end result is that Azure Active Directory connects GitHub to Power Platform, securely. You may have to read that sentence several times. I did. You will need to repeat this for each environment used.

Azure AD — "New registration"

• Sign in to Azure portal.
• Select "Azure Active Directory" from the menu and then select "App registrations".
• Click "New registration".

Azure AD — "Register an application"

• Set the "Name" to something you will understand in the future for example "POWER_YOURNAME_DEV - GitHub Actions", "POWER_YOURNAME_TRIAL - GitHub Actions" and "POWER_YOURCOMPANY_DEFAULT - GitHub Actions"
• Select "Accounts in any organisational directory" from "Supported account types".
• Set the "Redirect URI" to a meaningful web page you control.
• Finally, click "Register"

Azure AD — "Application (client) ID"

• Choose "Overview" and then find "Add an Application ID URI" and make sure it is filled out.
• Now copy the "Application (client) ID" somewhere safe like an editor text file as it is needed in the configuration later.

Azure AD — "ALM - GitHub Actions | Manifest"

• Click on Manifest in the menu
• Edit "allowPublicClient" and change its value to "true". and then Save the Manifest

Azure AD — "API permissions"

• Click "API permissions"
• Click "Add a permission".
• Search for "Dataverse" and select it

Azure AD — "Request API permissions"

• Click "Delegated Permissions"
• Select all the options
• Click "Add permissions" - ignore that it may display the Dynamics CRM logo.
• Click "Add a permission" again
• In the "Microsoft API's" tab choose "Dynamics CRM"
• Click "Delegated Permissions"
• Select "user_impersonation" 
• Click "Add permissions"
• Click "Add a permission" again
• Choose "APIs my organization uses", search for "PowerApps-Advisor" and select it in the results list
• Click "Delegated Permissions"
• Select "Analysis.All rights", and then choose "Add permissions"

Once you have completed these rather tortuous steps you have registered an application in Azure Active Directory.  

Azure AD — "Certificates and secrets"

• Choose "Certificates and secrets" 
• Click "New client secret"
• Add a description and copy the text that represents the secret to somewhere safe (for example in a password manager vault) as you will need them later and will not be able to view them again. 

Power Platform Application user

Back in Power Platform Admin centre, there's more admin to do! 

• Add an "Application User" as a user for your Power Apps environments. This is what is going to connect GitHub via AAD to Power Platform.
• Go to Environments and for each environment in turn:

  • Open the environment  and in Settings choose "Users + permissions" and then "Application users".

  • Select "+ New app user".

  • Select "+ Add an app"  and select the application registrations you just created from in Azure AD.

  • Under Business unit, select your environment as the business unit.

  • Under Security roles, select System administrator, and then select create.

• Once you have completed this for each environment your new service principal will have the necessary access for GitHub to the environments.

Remember, this is my particular strategy, based on the developer and trial environments only so you may need to adapt it to fit your specific organisations requirements.  Continue to Publishing Power Apps to clients production environments securely using GitHub with Power Platform (part 2), which deals with creating a simple Power App to deploy via GitHub.

References

See also:

• Create a developer environment with the Power Apps Developer Plan — Microsoft
• Quickstart — Register an app with Azure Active Directory — Microsoft
• Tutorial — Get started with GitHub Actions for Microsoft Power Platform — Microsoft