Power Platform pipelines

One of Power Platform’s weaknesses has always been its ALM (application Lifecycle management) capabilities. Version control and automatic release pipelines are included, but tuning these takes time. If the object of the work is small (it often is in Power Platform), this is often not seen as reasonable, but we end up exporting solution packages manually from one environment to another.

Another challenge is citizen development. The release pipelines familiar from application development are a total mystery for citizen developers coming from a completely different environment. The more difficult (doing and understanding) is made, the more surely citizen developers leave the game and return to making the solutions they need with Excel and SharePoint lists.

In this gap, Microsoft developed the Power Platform pipelines. A simplified, comprehensible version of the theme for citizen developers, which is also really easy to implement.

Does this solve all the problems?

Wait and see.

Necessary environments

First, let’s create all the necessary environments. Typically we have separate development, test and production environments.

The development is done only and only in the development environment, from which the finished version is taken to the test for testing. If everything is in order, the same version is taken to production for use by end users.

In order to be able to use Power Platform’s release pipelines, the production environment must be of type production environment. Other environments can be developer or sandbox environments.

However, we need one more environment (Pipelines Host). It is where all tasks related to publishing are performed. The environment must be a production environment and Microsoft recommends that it be dedicated to this use. So don’t use your current CoE environment for this purpose.

The same host environment can run several different release pipelines. So one host environment is enough.

Below are my own environments.

Installation

We have created the necessary environments. Next, we install the necessary application in the host environment (Admin Center -> Environments -> Pipelines Host > Dynamics 365 Apps).

Select the application to be installed (Power Platform Pipelines) and start the installation.

Let’s accept the terms.

Installation takes time.

After the installation is complete, we can make the necessary settings.

Configuration

Open the environment where the release pipelines will run.

Clicking on the name of the application (Solution Health Hub) opens the application menu. Let’s open the Deployment Pipeline Configuration from there.

This application manages publication pipelines. The application also shows the released releases with their steps (Run history) and the solution packages used in them (Solution artifacts).

Environments

The first step is to define which environments are included in our release pipeline. The environments in which development takes place are development environments. The remaining environments are target environments.

The required environment identifier (Environment ID) can be found in the Power Platform admin center.

This is how we have created the environments used in our release pipeline. Use their real names as the names of the environments. Makes it a lot easier in the future.

Next, the release pipeline is defined. There can be several of these, but we only need one this time. So this one.

Name the release pipeline and give it a description (1). After saving (2), we can attach the development environment (3) to it, which appears in the list of development environments (4).

Create a release pipeline that will be used to release App X (App X Pipeline).

Next, the stages of the release (Deployment Stages) are defined.

The first step is to publish the package from the development environment to the test. The publication stage preceding the first stage (Previous Deployment Stage) is left blank.

The second phase is the release from the test to production. It is always preceded by a release from development to test (Deploy to Test, Previous Deployment Stage).

The configuration is done and we can start publishing with this publishing pipeline.

The first time it took a little time, but in the future creating a new release pipeline will only take a few minutes. Totally unbelievable.

Typically, release pipelines are defined by someone other than the solution developers.

But what can be done with this now? How does this change what you do?

Deployment from development to test

Our example solution includes the following components

• Three boards
• Model-driven Power Apps
• Access role
• Environment variable
• Connection reference

All this is packed into one and the same solution package.

We have completed the first version and want to take it to the test environment for testing.

Let’s open the environment’s release pipelines (1) and choose which of them we want to use (2). We see that nothing has been taken to test and production yet. Let’s launch the release for the test (3).

Confirming the selection.

We are taking the package to a test, but the target environment does not have the connection required by our connection reference. The process forces us to create it in advance.

The same applies to environmental variables.

Finally, one more confirmation before the actual release begins.

And then we wait.

Ready!

After the test phase, we make changes and corrections in the development environment and perform the release again. We have tested versions 1.0.0.1 and 1.0.0.2.

Deployment to production

Deployment to production is done like a deployment to test. The first time, the missing components (connection and environment variable value) are created.

In the release chain, the latest version installed in the previous environment is always exported to the target environment. So in our example version 1.0.0.2.

Deployment history

Each deployment is saved on the host machine. We get to look at the history with the Deployment Pipeline Configuration application.

We can browse the different stages of the publication.

The packages used in the publication can be found in the artifacts.

What’s good about pipelines?

Pipelines finally offer authors an easy way to deploy their output to different environments. This enables a significantly wider use of separate development, test and production environments than at present.

In the deployment, the manual export and import of the solution package is completely omitted. This is a celebration if the organization has blocked file uploads with the MCAS service.

From the solution package, you can also directly see which versions of it have been installed in which environment and when.

What’s bad about pipelines?

After all, these still have their own shortcomings. For example, you can’t (at least not yet)

• Restores the environment to the previously installed version
• Connect the release pipeline to version control, so that you always get everything for yourself as well
• Add self-made workflows to the release process (e.g. approval receipts from testers, then automatic release to production)

However, the biggest stumbling block for many may be the managed solution packages used by the release pipelines. If you have already installed unmanaged solution packages in the test/production environment, you must first change them to managed.

There is an active debate in the Power Platform (and Dynamics 365) community about whether managed or unmanaged solution packages should be used. Microsoft recommends managed, the community mainly unmanaged.

However, in my opinion, publication pipelines are perfectly suitable for use, if the solution as a whole (excluding flow and Canvas Power Apps) can be placed in one solution package. However, I do not recommend implementing these on your own, if the understanding of the solution packages and the possible dependencies of their contents is not sufficient.

Otherwise, the risk of any kind of confusion is considerable. Maybe more about that in the next story.