This article will explain how to apply Application Lifecycle Management (ALM) in Azure DevOps for Power Apps. It will be shown how to set up the required Azure DevOps environment. Furthermore, it will be described how source code/Power Apps can be versioned, quality assurance can be performed and subsequently artifacts delivered to the production environment.

The history of the article is longer. The first draft was already written by me in 2019. In the meantime I have worked on it again and again. What finally kept me from publishing it was, in my opinion, not yet "finished" tooling of the "Microsoft Power Platform Build Tools for Azure DevOps - Power Platform | Microsoft Docs". The originally available tooling (Azure DevOps Extension) is still available now but has been marked as "DEPRECATED" since the jump to version 0.3.7. Already since the jump from version 0.1.16 to version 0.3.6 the original tooling has been fundamentally revised/improved.

In version 0.1.16, the access credentials (user name/password) had to be stored in plain text to set up the connection. Since version 0.3.6 this authentication can finally be setup using Service Principals.

Authentication methods Figure: Authentication methods

The old (not recommended) method (yellow) is still available. So the transition to the new option (green) is seamless, even for users who have already used previous versions of BuildTools or have not yet set up Service Principals. When changing to or starting with the current version of the Build Tools, you should always be using Service Principals.

Two versions are available in the Visual Studio Marketplace: 1. Power Platform Build Tools - Visual Studio Marketplace
2. (DEPRECATED) PowerApps BuildTools - Visual Studio Marketplace

As described above, this extension [2] is now marked as "DEPRECATED", so only [1] should be used.
The tools currently available for Azure DevOps are basically a wrapper around the SolutionPackager for D365 Customer Engagement (CRM).

The final architecture, for the integration of Azure DevOps and Power Platform, will look like the following on an abstract level.

Architecture overview Figure: Architecture overview

Microsoft itself suggests two different approaches for ALM in conjunction with the Power Platform. [^1] In this article the first variant is described, where only the source code is versioned, but not the packed solutions. In the context of classical software development this is also the normal way, because usually only source code and not compiled binaries are versioned.


Basically, a few things are needed to be able to follow the steps. The following components are required.

Getting started

As mentioned above, three environments are required to follow this guide. For the following steps the following environments with the corresponding definitions are used.

Name Function
André Bering's Environment DEV
Johanna Lorenz's Environment BUILD/QA
Alex Wilber's Environment PROD

As you can see, these three environments are visible in the Power Platform Admin Center.

Environment overview Figure: Environment overview

Having a background as a developer, the first question that might arise is how to version control your work in the Power Platform. At the moment there is no easy way to do this. The only way is to manually download the solution, unzip it and then version the content.

This process can be mapped into Azure DevOps using ALM, even with a kind of CI/CD approach.
The article is mainly based on the Microsoft tutorial for the Power Apps Build Tools, which can be found here.

For the tutorial and the further steps the URL of the respective environment is required. The URL can be found in the Admin Center.

Admin Center - Environment URL Figure: Admin Center - Environment URL

If any form of ALM is to be used with Power Apps, it is first necessary to understand how solutions work in this context. To understand these basics you can read this Microsoft Docs article: Solutions in Power Apps - Power Apps | Microsoft Docs

In this article there is another introduction linked, which should be read: Introduction to solutions - Power Apps | Microsoft Docs

Service connections / Service Principals

To be able to set up the connection in Azure DevOps, the corresponding Service Principal must be set up or stored in Azure DevOps. The corresponding menu item is located below "Project Settings - Pipelines - Service connection - New service connection".

Azure DevOps Service - Create new service connection Figure: Azure DevOps Service - Create new service connection

Azure DevOps Service connections Figure: Azure DevOps Service connections

In the dialogue, reference is made to two places which should help to create the corresponding access or to store it in the correct place. The first link refers to instructions in Microsoft Docs. There it is recommended to create the access using a linked PowerShell script. However, the script can only be executed under Windows because the PowerShell modules used require "System.Forms" and these are only available under Windows. Therefore I recommend that the Service Principal is created directly in the Azure Portal. The corresponding documentation is linked in the continuous text of the manual.

Use Single-Tenant server-to-server authentication (Common Data Service) - Power Apps | Microsoft Docs

After the Service Principal(s) have been created in Azure in, the setup can be continued.

The crucial point is that there is not the item "Settings" as in the manual, but the item "Advanced Settings". This item can be used to call up the corresponding interface.

Settings - Advanced Settings Figure: Settings - Advanced Settings

At this point, you might be surprised when the Dynamics 365 interface appears. The two platforms are very closely intertwined, so that certain settings are currently only (still) found in the old interface. The changeover to an end-to-end management interface is an ongoing process. Therefore it can be assumed that in the future the points will also be integrated into the power platform interface or a uniform look and feel.

There is another stumbling block in the Microsoft documentation, namely the creation of the user. However, the behavior regarding this stumbling block was not consistent.
For this reason, the following are the individual dialogs that must be processed to make the Service Principal known within the power platform environment.

D365 Settings Figure: D365 Settings

D365 Security Figure: D365 Security

In the user list view, filter to "Application Users" and then click "+ NEW".

Filter user list Figure: Filter user list

Before entering the data, the dialog must be switched to the correct mode by selecting "Application User".

Select 'Application User' Figure: Select 'Application User'

When entering the data, the information that was previously defined when the Service Principal was created in the Azure Portal must be used. The user also needs (because it is a mandatory field of the form) an e-mail address, even if it is only a technical user account. Here, for example, addresses of so-called example domains (example domains - Wikipedia) can be used, as can be seen in the following screenshot However, the address is not used for sending e-mails.
After creating the user by clicking the "SAVE" button, do not close the not dialog.

Enter user information Figure: Enter user information

Using the button "MANAGE ROLES" the necessary role must be assigned to the user account.


To be able to perform all necessary actions with this user account, the role "System Administrator" must be assigned. Otherwise, errors will occur later in the context of using this accountby the Azure DevOps Pipelines.

User role selection Figure: User role selection

After this step the account is set up and can now be stored in Azure DevOps. For this purpose the dialog which is shown/described at the beginning of this section ("Service connections / Service Principals must be used.

An individual Service Connection must be created for each power platform environment. In total, the setup described above must be carried out three times, whereby the Service Principal does not have to be created three times. The Service Principal can be stored as a user account in each environment.
Alternatively, a separate Service Principal can be created for each environment.

Azure DevOps Service connections list Figure: Azure DevOps Service connections list

Then create all required connections with the respective information/access data per environment.

Azure DevOps Service connection properties Figure: Azure DevOps Service connection properties

As described in the section "Getting Started", the URL of the environment is required and this value is stored as "Server URL" in Service Connection properties.

Azure DevOps Pipelines


Once the Service Connections have been created, the pipelines and releases must now be set up. These are used to extract the source code from "DEV", create a Managed Solution in "QA/Build" and then roll out this Solution in "PROD".

One pipeline is required for each of the first two steps.

Azure DevOps Pipelines list Figure: Azure DevOps Pipelines list

An Azure DevOps release is then used for the final deployment towards PROD.

Azure DevOps Releases list Figure: Azure DevOps Releases list

Repository permissions

Below "Project Settings - Repos - Repositories User" the account "\<Azure DevOps Project Name> Build service (\<Organization name>)" must be granted the "Contribute" permission. Otherwise, the build pipeline cannot push the source code into the repository.

'Build Service' permissions Figure: 'Build Service' permissions

Solution export

There are four steps in the pipeline for exporting the solution and one more for adding the code to the repository.

Azure DevOps pipeline tasks Figure: Azure DevOps pipeline tasks

To add the source code to the repository, a few command-line commands are required to have Git run automatically in the context of the pipeline.

Azure DevOps pipeline command line task Figure: Azure DevOps pipeline command line task

The variable should be emphasized here. This must / can be set when the queue is started. This means that the respective commit comment can always be set dynamically during the respective run. The code for this task can be found in the following section.

Source code in repository

The commands are used in the final step "Commit solution to repo" to add the code to the repository.

echo commit all changes
git config "<E-Mail address of commit user""
git config "Automatic Build"
git checkout master
git add --all
git commit -m "$(CommitMessage)"
echo push code to new repo
git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" push origin master

Create managed solution

After the solution has been extracted from the DEV environment, it must be transferred to the BULD/QA environment where the managed solution is created.

Azure DevOps pipeline tasks Figure: Azure DevOps pipeline tasks

For this purpose, the two tasks "Power Platform Import Solution" and "Power Platform Export Solution" are used in the context of the pipeline. For the latter task it is important that the option "Export as Managed Solution" is activated.

Option »Export as Managed Solution« Figure: Option »Export as Managed Solution«

In the last step of the pipeline, the exported solution is published as pipeline artifact. This step is important so that the solution created in the context of the release can then be rolled out in the production environment.

Deployment to PROD

With a release, the solution is rolled out into the "PROD" environment. In this case, the artifact previously created must first be linked to the Release in the "Artifacts".

Release pipeline - artifact properties Figure: Release pipeline - artifact properties

This way the artifact can be used in the tasks of the release. It is important that the "alias" of the artifact is part of the path specification in the task for the actual deployment. There is no variable within Azure DevOps for this variable part. The reason for this is that more than one artifact can be used in a release and therefore a unique relationship between variable and artifact would not be possible.

Release Pipeline - artifact alias Figure: Release Pipeline - artifact alias


As mentioned in the beginning, the Power Platform Build Tools are basically just a wrapper around the tooling for customer engagement. They can be installed and used as in the following instructions.

Use the SolutionPackager tool to compress and extract a solution file

Afterwards, all tools are installed in order to be able to perform the previously described steps manually locally. At this point, however, it is recommended to choose the ALM path using Azure DevOps for the sake of cooperation.


A developer may be used to a different approach when it comes to versioning source code. However, development on the Power Platform brings with it special peculiarities, which include a different approach to this process.


  1. Application lifecycle management (ALM) with Microsoft Power Platform - Power Platform | Microsoft Docs
  2. Application lifecycle management (ALM) basics with Microsoft Power Platform - Power Platform | Microsoft Docs
  3. Configure service connections using a service principal - Power Platform | Microsoft Docs
  4. Configure user security in an environment - Power Platform | Microsoft Docs
  5. Use Single-Tenant server-to-server authentication (Common Data Service) - Power Apps | Microsoft Docs

[^1]: "There are two main paths you can use when working with solutions in a source control system:..." - ALM for developers - Power Platform | Microsoft Docs, Retrieval: 24.06.2020

Add your reply here with Webmention (you must link to this page in its canonical form)
Webmentions are approved manually. Will take some time until they show up.