by Simon Doy

How the Power Platform Build and Release pipelines work


Introduction

Photo by Dan Gold on Unsplash

This post is part of a series of posts discussing my experiences with putting in place Dev Ops processes around the Power Platform.

If you have not read the introduction post, I would suggest starting there.

If you have read it then, that is great and thanks for taking time out of your busy schedule to read this.

As mentioned, there are two core pipelines, the build pipeline, and the release pipeline. This blog post will delve into how they work currently. I fully expect that they will change as I get feedback from the community.

I really look forward to that as I am sure they can be better! I have some ideas on some tweaks that need to be made.

Anyway, let’s get started.

The Build Pipeline

So, the Build Pipeline has a parameter block and a set of variables.

The parameter is used to decide whether the build should create a managed or unmanaged solution.

The parameters section

The variables are used to identify the solution (PowerPlatformSolutionName) that needs to be exported and the name of the environment (PowerPlatformEnvironmentName) that the solution needs to be exported from.

The final variable provides the major, minor, and revision numbers as the version prefix for the solution version. The build number is handled by a counter managed by Azure Dev Ops.

The first set of tasks install the Power Platform Build tools including the Power Apps CLI that are required to work with the Power Platform solutions.

Next, we resolve where the PAC tools are installed on the build agent and set the version number.

We then publish the customisations in the environment. This makes sure that we are using the latest version and if a developer has forgotten to publish something it will get picked up.

Then we set the solution version based on the build version. I like this as you can now tie the build / release process to the solution deployed to Power Platform!

Next, is exporting the solution. We do this twice! Once as an unmanaged solution and again as a managed solution. This means we have a copy of the solution held in source control in case something happens to the source Power Platform environment.

The next step extracts the solution settings, environment variables and connection references.

Next, we unpack the solution so that we can get the environment variables and blank them. This makes the solutions easier to port into the other environments. Also, if we want to apply settings as part of the release, we can do that!

Once we have extracted the environment variables and cleared them out, then we can pack the solution back up.

Finally, we take a copy of that solution settings file and use the Azure Dev Ops Publish Assets task. This associates all the files in the Artifacts Stage directory to this build.

These can be seen here.

Phew, let’s talk about the release pipeline!

Release Pipeline

The release Pipeline has been covered in a previous post a little but let’s discuss how it works.

These release or deployment pipelines need to deploy something. That something is referred to by the resources tag. In our example we are referring to the build Pipeline assets.

When you run the release Pipeline you can see here that the files are downloaded by the Download Artifacts task.

The release process will deploy to the various stages defined by this YAML script.

However, the main logic to deploy is held in another YAML file, as shown by the template parameter.

Let’s look at that YAML file!

This starts with a set of parameters that are used to deploy the solution.

The release is quite simple and to be honest there are some more things that we can do. For example, apply settings to the solution. However, I wanted to keep this part simple.

So, initial steps show the files that are part of the release (for debugging purposes).

Then we have a task which could be used to replace tokens. This might be used for example to set values in the settings file. (More on that in another post).

Next then we install the tooling using required for the Power Platform deployment.

The final task performs the actual deployment into the Power Platform solution into the environment using the PowerPlatform import solution task. This also applies the settings via the DeploymentSettingsFile parameter.

And to be honest that is it!

Conclusion

So, in this post we have covered how the pipelines work. I hope that it has been useful. I am sure you will have some improvements to suggest. Also, I bet there are some other ideas for what could do done here. If you do, I would love to hear them!

In the next post I will discuss some common issues that we have seen when deploying the solutions with these processes.

by Simon Doy

My experiences and an approach to implementing Power Platform Dev Ops with the Power Platform Toolchain: Introduction


Introduction

At iThink 365 we use Dev Ops processes to build and deploy our software built with Hi-Code. We have standardised our approach for building and deploying our .NET, Node.js, React, and Angular based solutions into Microsoft Azure.

I love Dev Ops as it gives me and the team confidence that we can build and deploy software to our customers without remembering all the detail. The approach reduces stress, and we can deploy new versions of our solutions in a repeatable and consistent manner. This saves us a lot of time, stress and energy.

I was keen that we apply Dev Ops processes to our Power Platform development teams. So, we embarked on a journey to organise our processes. They are not perfect, but we have been working and using the approaches that are discussed for the 12 months.

This blog post represents the first in a series of blog posts which delves into the delivery of Power Platform solutions using Dev Ops. We currently use Azure Dev Ops for our source control. Therefore, the build and release pipelines which we will describe are for Azure Dev Ops rather than GitHub Actions.

If you want us to look at Github actions, leave a comment and I will see about creating a version for Github.

I keep saying Power Platform solutions but really, I am talking about Power Apps and Power Automate delivery.

The blog series has the following articles:

So, let’s get started with some background and explanation of some terms first.

Difference between Build and Release

I have a bit of a pet peeve about how the terms Build and Release are used. Often, I see approaches which I believe should be part of a release process being included in the build process. This is regularly seen with SharePoint Framework projects where build processes deploy content into Azure Blob Storage.

To me, build is the process that builds the artifacts. These might be compiled code, assets, configuration templates. These artefacts are then held within Azure Dev Ops as assets associated to the build pipeline. To show you what I mean let’s look at the screenshot below which holds assets published as part of that instance of the build.

Build Pipeline showing you the assets that have been associated to the build.

The build creates the assets, sets the version number of the assets and packages them up so that these assets can be released together.

Now to me release processes are purely about deploying the artefacts that have been built by the build process. The release process may and will apply configuration settings for the environment. This is so that the solution once it has been deployed works correctly in that environment.

Configuration will be talked about further but is achieved by taking those build assets and replacing tokens in configuration files within the build assets and then deployed to the environment. Configuration items include items such as database connection strings, SharePoint list identifiers, URLs for talking to back-end APIs.

The point is that build is the creation of the assets and should not deploy anything into an environment. The release process should oversee deploying and pushing assets into the environment.

Power Platform Solutions – Managed and Unmanaged

Solutions are packages of Power Platform customisation such as tables and forms and they are used to group an application and the assets as one package. Solutions enable the application and all its dependencies to be deployed together.

There are two types of Power Platform solutions,

  • Unmanaged
  • Managed.

The difference between the two is that an Unmanaged solution can be changed (customized) when it is deployed into another environment. An unmanaged solution is seen as something that is still in development.

Managed solutions are used to deploy a solution that is complete. These solutions are deployed to a Test or Production environment, and it cannot be changed once it is deployed. However, if the solution allows customisations of the assets it contains, they can be used in another solution and customised inside that other solution.

For more information, check out this Microsoft documentation on solution concepts.

Environments

The last concept that I would like to cover is Environments. These are a way of having separated containers for running your applications.

At iThink 365, when we build solutions for ourselves, we use three environments for our applications. These are:

  • Development
  • Testing
  • Production.

When we are working on our customer solutions then we have four environments which are:

  • Development (iThink 365 Dev)
  • Testing (iThink 365 Dev)
  • UAT (Customer)
  • Production (Customer)

The UAT and Production environments in these cases are held within the client’s Power Platform tenant.

Solutions flow through from Development -> Testing -> UAT -> Production.

This approach allows us to be confident that we can make changes to the solution in development. Whilst ensuring testing can take place without being impacted by ongoing development or developers being affected by the testing process.

This approach allows us to build up the confidence of the client.

Next

In our next article, I will show you how to get setup in Azure Dev Ops to build and deploy your Power Platform solutions.