How to distribute solutions from one Power Platform environment to another (Part 2)

Updated: Mar 28, 2021

In the part 1 (https://www.dataobjectexception.com/post/3-power-platform-build-tools-capabilities), I could enter a brief description of Power Platform Build Tools and its 5 potential scenarios :

1- Scenario 1: Distribute the solutions from one environment to another

2- Scenario 2: Only commit a solution file to the source control

3- Scenario 3: Consolidate the solution into an artifact

4- Scenario 4: Centralize the distribution of the solutions between environments in one azure pipeline

5- Scenario 5: Create multiple consolidation pipelines to transfer partial customization


Here, I intend to provide the procedure related to the scenario 2, "Distribute the solutions from one environment to another" : deploy the solutions from one environment (dev) to another (test).


Requirements


1- Create your environments using Power Platform Admin Center: https://admin.powerplatform.microsoft.com/?l=en-US


  • Create a source environment or dev environment as sandbox

  • Create a target environment or test environment as sandbox

Of course, this is a question of user preference and so, you call them as you wish.

Administrate the environments
Power Platform Admin Center and environments

2- Create your organization in Azure Devops : https://dev.azure.com/

Create your organization in Azure Devops
Azure Devops and Organization

3- Make sure you have the minimum admin privileges in Azure Active Directory (AAD): Azure provides built-in security roles. If you have the following security role "Application Administrator", it would be enough because it can create and manage all aspects of app registrations and enterprise apps in Azure. If you are "Global administrator", we don't need to manage this one.

Application administrator
Security Role in AAD : Application Administrator

Step 1 - Create and Manage the apps in Azure Active Directory


1- Log into your Azure Active Directory : https://aad.portal.azure.com/

2- Click on "App registrations"

3- Click on "New registration"


4- A form will appear and fill the form with the following details

5- Click on the button "Register". It will open a specific form.

6- Click on the button "View API permissions" and "API permissions" form will appear.

7- Add a permission to the "App registration"

8- Add the "Dynamics CRM" permission

9- Select "Delegated permissions" and "user-impersonation"

10- Click on the button "Add permission" and the permission will added to the application

11- Add the client secret to allow the external application to have access to Power Platform (environment)

12- Add a new client secret clicking on the button "New client secret"

Step 2 - Create the application user in your Power Platform environments


1- Go back in the Power Platform Admin Center


2- Open your environment


3- Click on "Advanced Settings"


4- Click on "Security"

5- Display the list of all users

6- Switch to the "Application Users" form


7- Click on the button "New" and a new form will display

8- Fill the field "Application ID" and click on "save"

Step 3 - Create the project in your Azure Devops Organization


1- Create your projects in your organization, previously created in Azure Devops


1-1 Click on the "New project" button. It will open a new form.

1-2 Fill the form

1-3 Click on "Create" button and it will create your project

Step 4 - Handle the project settings - Service connections


First, I'll create 2 service connections : one for the dev environment and another for the test environment.


1- Click on the button "Project settings", it will display a menu

2- Click on the menu "Service connections"

3- Click on the button "New service connection". In the search field, write "power" and select "Power Platform". After, click on the "Next" button.

4- Fill the form "New Power Platform service connection".



- Server URL is your environment (Dynamics 365 Organization)




- Tenant ID is your tenant information (Azure Active Directory)


- Application ID is the Guid of your App registrations (you can get it from your Tenant in the app registrations menu)


- Client secret is linked to you app registrations. It will prove its identity when requesting a token.


- Service connection name : a relevant name. It's up to you.



Click on "save" button.


Do the same for your test environment.


Step 5 - Create your Azure Pipelines


We are going to create our deployment pipeline from dev environment to test environment.


1- Click on the "New pipeline" button

2- Choose the classic editor

3- Select your own repository. I selected "Azure Repos Git" and clicked on "Continue".

4- Select a template: "Empty job"

5- Update the build pipeline

6- Update the "Get sources" form, if needed.

7- Edit the default Agent job

Warning: No need to check "Allow scripts to access the OAuth token". It will retrieve the PAT (Personal Access Token) you just created. But, for this scenario, as we do not use a command line script, we don't need it.


Once, you specify you agent pool, you need to specify your agent : I choose vs2017-win2016.

8- Add the tasks to your agent by clicking on the "+" button

9- Search the task regarding Power Platform. The lookup will display all tasks related to the solutions deployment.

10- Add the tasks we need to execute our scenario. Please, follow the sequence as below.

- Power Platform Tool installer is always the 1st step.

- Power Platform WhoAmI will help to test the connectivity.

- Power Platform Publish will publish the customizations.

- Power Platform Export will export the solution as unmanaged and/or as managed, from the environment.

- Power Platform Import will import the solution as unmanaged and/or as managed, in the environment.


11- For each task, configure the settings. we can rename all the tasks a we wish.



- In task "Power Platform Tool Installer", Make sure the check box "Use default versions" is checked.


- In task "Power Platform WhoAmI", select the authentication type (Service Principal/client secret); select the service connection previously created (connection to the dev environment).



- In task "Power Platform Publish Customization", select the authentication type (Service Principal/client secret); select the service connection previously created (connection to dev environment).



In task "Power Platform Export Solution", select the authentication type (Service Principal/client secret); select the service connection previously created (connection to dev environment).Set the variables : Solution Name ($(SolutionName)) and Solution Output ($(Build.ArtifactStagingDirectory)\$(Solutio nName).zip) File.

In task "Power Platform Export Solution", select the authentication type (Service Principal/client secret); select the service connection previously created (connection to dev environment).Set the variables : Solution Name ($(SolutionName)) and Solution Output ($(Build.ArtifactStagingDirectory)\$(Solutio nName).zip) File. Make sure, you have selected "Export as Managed Solution".


- In task "Power Platform WhoAmI", select the authentication type (Service Principal/client secret); select the service connection previously created (connection to the test environment).



In task "Power Platform Import Solution", select the authentication type (Service Principal/client secret); select the service connection previously created (connection to test environment).Set the variable : Solution Output ($(Build.ArtifactStagingDirectory)\$(Solutio nName).zip) File.

Check the option "Overwrite unmanaged customizations".

- In task "Power Platform Publish Customization", select the authentication type (Service Principal/client secret); select the service connection previously created (connection to test environment).



12- We can extract the YAML of our agent job and validate the content of our tasks

13- Handle the variables used during the execution of the pipeline : SolutionName

Step 6 - Run and Queue your Azure Pipeline


1- in the menu of the Azure Pipeline, click on the "Save& Queue" button or the "Queue" button.

When we click on the button, the job is queued and is going to run.

2- Job is running

The job is running and the pipeline is displaying logs we can easily view.

We can access the details, clicking on the job. And, we can click on each task to view progress. After a few minutes, the pipeline should be complete and the solution should be in the test environment.

3- Job is complete

Access to the scenario 2 as second example : How to commit a Power Platform solution file to the source control (Git) - Part 3

240 views0 comments