Power Platform build tools and Azure DevOps

We have had a lot of requests to clarify best practices for using Power Platform Build Tools (PP.BT) for Azure DevOps and are delighted to share more about this in our post below.

Username and password versus Service Principal

When using Azure DevOps, the Power Platform Build Tools provides you options to either create service connections i.e., username and password or Service Principal (SPN). We recommend that you use Service Principal instead of username and password. There is nothing wrong with username and password, it is just that when you have Multi-Factor Authentication enabled, it will break your pipelines. You can use a generic service account as well, but just make sure not to enable MFA for that service account.

Figure 1: Service Connection with Username and Password

Figure 2: Service connection with Service Principal accounts

To create a service principal registration, please use the steps listed in the following location: https://learn.microsoft.com/en-us/power-platform/alm/devops-build-tools#configure-service-connections-using-a-service-principal

When using service principals, it is important to understand that service principal used to run your pipeline can and should be different from the service principal authentication you use to your backend data source in the application you are deploying. They should be different SPN’s as a best security practice.

Power Platform tools installer

When creating your pipelines your first task is to install the Power Platform Tools installer. The purpose of the task is to install the latest version of the Power Platform tools to run your builds

Figure 3: Power Platform Tools installer

Set Service connections

Service connections contain the credentials to use for the backing APIs.  In scenarios were the pipelines need to perform tasks that we do not offer in the Build Tools; we often see users adding Powershell or direct API calls in their pipelines. Set Connection Variables allow the credentials inside the Service Connection to be shared securely for use with Powershell and any other cli that needs those credentials to get a token for the same identity in the service connection.

Administrative tasks

Creating ephemeral test environments and assign user

The Build Tools includes the ability to create and delete environments. This enables you to create a test environment on the fly, load the application to be tested, test the application and then delete the environment as part of the CI/CD process. Although the Application testing part in this case is manual today, in the future, we expect to fully integrate the Test Engine effort into the Power Platform Build Tools in the near future.

Some users use other community-based testing tools to accomplish such capability as well.

You can also use your Azure Pipelines to backup, restore and copy environments.

When using a SPN to create such environments, note that the SPN becomes the owner of these created environments. If you want to change the ownership of these environments to be an interactive user or another SPN, we have introduced a new task called assign user.

Figure 4: Assign user task

Username can be an application id or a user object id and the Role has to be a role in Dataverse for the newly created environment.

We encourage you to explore some of the other administrative tasks available to Power Platform Build Tools for Azure DevOps.

solution tasks

Most of the tasks available are focused on solutions, since solutions are what you use for any Application Lifecycle Management (ALM) objectives on the Power Platform. When you want to move applications from Development to Test to Production, you should always ensure that all your applications, cloud flows, and bots are in a solution. The following solution tasks are available in the Power Platform Build Tools for Azure DevOps:

Figure 5: Solution tasks in Azure DevOps

Set solution version

Once you have successfully imported a solution to the target environment you can set the version on the imported solution. This is generally useful if, users want the solution version to mimic what is captured in the Git repository tag or if you want to keep the version numbers consistent across environments, especially when going from Test to Production. The version number is generally a 4 number tuple

Figure 6: Setting a solution version

Solution pack and unpack

When you are exporting a solution from the Power Platform environment, and before checking in the solution zip file into the Source Code repository you should always unpack the solution.zip to have the solution represented and understood by your source control system. Use the unpack command to extract the content and check it in to the repository. Consequently, when exporting a solution that is unpacked in a source code repository, you must pack the relevant artifacts back into a solution.zip in order to be able to import it and hence you have the pack command available for this.

Export solution

This task is self-explanatory. When you want to export the artifact from a source environment and put it into a Source code repository, you need to export the solution and this task is created to support such that.

Import solution and apply solution upgrade

Just solution export, solution import works in the inverse. But one of the interesting steps in importing a solution is especially when upgrades are in place. Remember, when applying upgrades, it removes unreferenced resources, you can import the solution as a holding solution.

Figure 7: Apply solution upgrade

Once the solution is imported as a holding solution then you can run the Apply Solution Upgrade task to complete the import and application of the new changes you are committing to the environment.

Add solution component

When importing a solution if there are other required components that need to be added, then you can list those specific components out. Hence when importing, all those listed components will be added. This will increase the size of the solution as a lot of the dependents will be pulled in. This is the same capability in the Maker UI, where you can add required objects.

Figure 8: Adding the solution component

How does one find out the component and the component type? When you unpack a solution and open up the solution.xml in the Other directory. In the solution.xml file there is a list of all the components and their respective component type.

Figure 9: Component and their component type

Publish Customizations

Although this is a top-level task it is to publish customizations for all the solutions in the environment. You can specify the environment URL or use the environment set in the variable and it will then publish all the customizations.

Figure 10: Publishing customizations

Deploy package task

When you have an application that spans multiple solutions, you can add them to a package. When such a package exists, you can deploy the package using this task. You can also specify the runtime sequencing of the applications.

Figure 10: Package deployment task

Conclusion

These are just a few of the details on how these tasks are used in the day-to-day function of Power platform in the context of a CI/CD environment in Azure DevOps. If you have additional feedback, please reach out to us via the following forums ISVFeedback@Microsoft.com or The PowerUsers community. Raise the issue and bugs at the following location in GitHub https://github.com/microsoft/powerplatform-build-tools