As you know, Azure Devops is a Microsoft ALM solution for general-purpose software development and provides several capabilities: agile planning and work tracking tools in Azure Board, repositories for source control in Azure Repos (git...), build and release automation tools in Azure Pipelines, testing support with Azure Test Plans and finally, Azure Artifacts for storing various tools and packages used in the build and integration process.

My intention is not to dig into Azure Devops capabilities, but to focus on Power Platform Build Tools provided by Microsoft. So, I would like to describe the 3 Power Platform Build Tools Capabilities (https://docs.microsoft.com/en-us/power-platform/alm/devops-build-tool-tasks).

Getting an overview of the 3 capabilities

The first capability is related to the “quality check” and “helper check” tasks

-- Power Platform Tool Installer: this task needs to be the first task in every Azure pipeline we just created. This task will install the necessary modules (PowerShell) required to execute the next tasks in our pipeline: PowerApps Administration, Package Deployment, PowerApps Checker, SDK Tools.

-- Power Platform WhoAmI: this task can be used to test the availability of your environment before a task with a transaction against an environment (i.e. sandbox environment) is triggered.

There is only a single quality-check task “Power Platform Checker”, which is used to trigger a quality check of a solution package using the “PowerApps Checker” tool. According Microsoft: “This task runs a static analysis check on your solutions against a set of best-practice rules to identify any problematic patterns that you might have inadvertently introduced when building your solution” (see information : https://docs.microsoft.com/en-us/power-platform/alm/devops-build-tool-tasks#quality-check).

The second capability is related to the “solution” tasks

Solution tasks can be used for various manipulations of the solution files and require the solution package file (zip file) to exist in the source environment (i.e. https://organization.crm3.dynamics.com/). Apparently, there is no task related to the creation of a solution (zip file), but we can a custom task (developed in PowerShell and calling the SK).

-- Power Platform Export Solution: this task can export an existing solution file from an existing environment as managed or unmanaged solution.

-- Power Platform Import Solution: this task can import a solution package (unmanaged/managed) into an environment.

-- Power Platform Set Solution Version: this task can set a version number of an existing solution in an environment.

-- Power Platform Unpack Solution: this task can unpack a managed or unmanaged solution into the files contained in the package. The unpacked packaged could be pushed into a source control system (git…).

-- Power Platform Pack Solution: this task can pack solution files into an unmanaged or managed solution package. The unpacked packaged could be pushed into a source control system (git…).

-- Power Platform Deploy Package: this task can deploy a package created with the “Package Deployer Tool” into an environment.

-- Power Platform Publish Customizations: this task can publish all customizations in an environment.

The third capability is related to the “environment management” tasks

Environment tasks can be used for various manipulations of the Power Platform or Dynamics 365 environments (i.e. https://organization.crm3.dynamics.com/).

-- Power Platform Create Environment: this task can create a new environment and we can select the region, target version, environment type, base language, currency, domain and even, a friendly-name.

-- Power Platform Reset Environment: this task can recreate an existing environment. So, first, this task will delete the environment and finally, will create a new one with the same parameters as the deleted one.

-- Power Platform Backup Environment: this task can create a backup of an existing environment (including the database).

-- Power Platform Delete Environment: this task can delete an environment (including the database).

-- Power Platform Copy Environment: this task can create a full or minimal copy of an existing environment (source) into a target environment. However, the target environment must exist.

Finally, we can observe a variety of tasks using the Power Platform SDK (software development kit). Moreover, all the task types could be used to implement several automations, with the standard capabilities of Azure Devops.

Capabilities integration in Azure Devops

First, all the task types could be used into Azure Pipelines. Hence, there are several scenarios (Power Platform ALM scenarios):

1- We can distribute the solutions from one environment to another.

2 - We can commit a solution file to the source control, using a command line capability. For example, we can commit our source code to git with git commands.

3 - We can consolidate the solution into an artifact using a “publish pipeline artifact” task.

4 - We can centralize the distribution of the solutions between environments and there would be one pipeline distributing every change in the centralized customization to every development environment.

5 - We can have multiple consolidation pipelines to transfer a partial customization from a specific development environment to the consolidation master environment.

Conclusion

As we can notice, Azure Devops supporting both the Continous integration (CI) and Continous Deployment (CD) principles, with Power Platform Build Tools is a great way to reliability of the deployment process regarding the solutions (containing entities, process, plugins, web resources, etc.). Just to mention that I only focused the CI part because I only mention Azure Pipeline in my introduction. Here's below my white paper you can download : "Introduction to Power Platform Build Tools Capabilities".

Access to the scenario 1 as first example : How to distribute solution from one power platform environment to another (Part 2).