The Power Platform is really great for building things quickly
but at some point - especially in an enterprise environment, you're probably going to want to use DevOps to export your code into a source repo and do deployments to higher level environments.
This article outlines the first step which is to establish a way for a DevOps to authenticate and access a Power Platform environment
DevOps uses Service Connections to authenticate against environments and you really have two types. You could create a Service Connection that just uses a standard user account or you could use a Service Principal.
With a user account, this will be treated like a normal user - so there may be license implications and is generally not the recommended method. With just a tiny bit of effort we can use Service Principals and therefore this is what I'll be demonstrating with.
- You will need to access your Azure Active Directory tenant and be in one of the following roles:
- Application administrator
- Application developer
- Cloud application administrator
- You will need to access your Power Platform environment and need to be a System Admin
- You will need to have DevOps permission to create service connections. You may also need further access to do things within DevOps depending on what you actually want to do with service connection (eg. create pipelines, save to repo)
Go to Azure Portal -> Azure AD -> App registration. Create a new registration.
Take note of the Application ID and Tenant ID (you'll need it later)
Go to the Certificates and secrets page and create a new client screet.
Just a few things here - the maximum length of time you can do is 2 years on the Azure Portal. You have two choices here - set a little reminder to regenerate this secret and change it for the places that use the secret, or there's also a way using PowerShell to create a secret that lasts up to 100 years (see this answer)
The other issue you might want to consider is where to store the secret. The secret is only shown once and then you cannot retrieve it after that. If you need to use it later on, you'll need to somewhere to store it - I would recommend using Azure Key Vault - and you can even then access it programmatically if you want to. In my case, I'm not going to store the secret anywhere. The only thing I'm going to use this secret for is my Service Connection, so I'm happy to re-generate a new secret if I ever need to edit this.
Next we want to create a user that the app registration will be connected to in Power Platform. The app registration will be able to act on behalf of this user.
In Power Platform environment, go to Advanced Settings -> Settings -> Security -> User and then Application User -> then click New
Paste the Application ID in and it'll re-populate the rest of the fields.
Grant this user system admin access.
Under Project Settings -> Service Connections, create a new service connection
Select Power Platform
Enter in all the details noting you'll need the tenant ID, application ID and client secret ID
A screenshot below shows a step in a pipeline which is an example of where you may use this Service Connection
This article shows how to set up the Service Principals in order for your DevOps pipelines to access your Power Platform Environment. In later articles, I will explain things you can do with this access which may include exporting and unpacking to save to a new git branch or creating release pipelines that'll automatically import and publish your solution into higher level environments as required.