Posts by Simon Doy

I am an avid SharePoint enthusiast who works as an Independent SharePoint Consultant based in Leeds, United Kingdom. I am one of the organisers of the Yorkshire SharePoint User Group in the United Kingdom. I have been designing and building SharePoint solutions since 2006.

Setting up Build and Release Pipelines to deploy Power Platform Solutions.


Introduction

This post is part of a series of blog posts which cover my experiences and an approach to using the Power Platform Dev Ops tool chain to deploy Power Platform solutions with Azure Dev Ops.

If you are reading this and have not read the other articles, I recommend starting with the introduction post.

This post will discuss how to set up the build and release pipelines in Azure Dev Ops and discuss how they work.

Get the code

All the source code for the Pipelines can be found in my company’s GitHub Repository, https://github.com/ithinksharepoint/powerplatformdevops.

You will need to get the Github code and put this into your Azure Dev Ops Project Repository. At iThink 365 we create a folder called dev-ops in the root of the repository to hold these pipelines.

The dev-ops folder

Within the dev-ops folder are the following files:

  • i365-powerplatform-solution-build-pipeline.yml – this holds the build pipeline code.
  • i365-powerplatform-solution-release-pipeline.yml – this holds the release pipeline code.

The templates folder is used by the release pipeline to hold the deployment process. One of the beautiful things about YAML pipelines is that you can create templates, reuse, and link to them so that all deployments use the same approach.

The following setup will configure the following: 

  • Power Platform Build Pipeline 
  • Power Platform Release Pipeline 

The Build pipeline oversees publishing all customisations and exporting the solution out. It also unpacks the solution and associates the artifacts to a published asset which is attached to the build. 

One of the challenges that I faced with solutions is the management of environment variables. When you export solutions out from Power Apps or Power Automate with the user interface you need to clear out the environment variables before you export. 

This is a bit of an annoying step, the advantage of using the Power Platform Build tools is that the export solution step does this for you, so you don’t have to remember. So even if you implement the build pipeline it will leave you with a zip file which has your solution ready to go to be imported into another Power Platform environment! 

The release pipeline ensures that the solution built by the build pipeline is installed into the desired environment. 

Something to be aware of is the idea of managed and unmanaged solutions. A managed solution is setup so that you don’t change its configuration of it when imported into another environment. Unmanaged solutions are built to be changed for example they may be exported and put into your source control system for example. 

Setting up the Build and Release Pipelines

To setup the build and release pipelines do the following from within Azure Dev Ops.

Build Pipeline

  • Open Azure Dev Ops
  • Open the Project
  • Click on Pipelines, then Pipelines
  • Click New Pipeline
  • Choose Azure Repos Git
  • Select the repository that holds the pipeline YAML
  • Choose Existing Azure Pipelines YAML file
  • The select an existing YAML file task pane will appear and read all the YAML pipelines in the repository.
  • From the path drop-down select the pipeline i365-powerplatform-solution-build-pipeline.yml
  • Click Continue
  • The Review Your Pipeline screen will appear.
  • Click Run -> Save to create the pipeline.

The pipeline created will be given the name of your repository, so we need to change the name.

  • Click edit
  • Click the three dots and then choose Triggers
  • Now we can rename the build pipeline to something more suitable.
  • At iThink 365 we use the naming convention [Application Name] Build CI.
  • Change the name and then click on Save.

Next, setup the build variables so that the pipeline knows which solution to build and where that solution is held.

To setup the build variables:

  • Edit the Build Pipeline that we just created

  • Click Variables
  • Click New Variable
  • Create a variable called PowerPlatformEnvironmentName
  • The value should be the name of the Service Connection that you created for the Power Platform environment that holds the development version of your Power Platform solution. In our case that is Development and our value is Power Platform Dev Environment (dev.ithink365.co.uk).
  • Click Ok to add the variable.
  • Now add another variable called PowerPlatformSolutionName
  • The value should be the internal name for your solution. This can be found by looking at your solution and use the value from the name column.
Use the name of the solution rather the display name.
  • Last variable to add is called version.MajorMinor
  • This is the version number of the solution to use for the first three digits.
    • e.g. 1.0.1
  • Click Ok
  • Click Save to finish

Now your build pipeline is ready for use.

Let’s run the pipeline and make sure it is working.

  • If you do not have the pipeline open, then open and click Run Pipeline followed by Run

Wait for the pipeline to do its work, hopefully it will find your Power Platform environment and solution.

To view the pipeline, click on Job and you will see the pipeline output.

You will be asked to confirm that the pipeline can connect to the Power Platform environment when you run the build for the first time. So approve that request.

Wait for the job to complete, hopefully you will see a sea of green ticks as shown below.

If you do not then check the error message and use that to diagnose the issue. I will cover some of the common issues in a subsequent blog post. [TODO: add link to blog post]

Also, I will provide more details on how the build pipeline works in subsequent blog post.

Release Pipeline

Now with the Build pipeline working we need to release the code. So let’s setup the pipeline for releasing the solution into your environments.

So, following the same process for the Build Pipeline lets add a new pipeline.

  • Open Azure Dev Ops
  • Open the Project
  • Click on Pipelines, then Pipelines
  • Click New Pipeline
  • Choose Azure Repos Git
  • Select the repository that holds the pipeline YAML
  • Choose Existing Azure Pipelines YAML file
  • The select an existing YAML file task pane will appear and read all the YAML pipelines in the repository.
  • From the path drop-down select the pipeline i365-powerplatform-solution-release-pipeline.yml
  • Click Continue

Next, we need to add a variable called PowerPlatformSolutionName. This is slightly different as it is the name of the solution zip file. So, use the value that you used for the build pipeline but add Solution.zip to the end.

For example, our solution was called iThinkHR and its zip file name will become iThinkHRSolution.zip.

  • Click OK
  • Click Save
  • Click Save once again to create the pipeline.

We have created our pipeline, of course we need to give it a good name.

  • Click edit
  • Click the three dots and then choose Triggers
  • Now we can rename the build pipeline to something more suitable.
  • At iThink 365 we use the naming convention [Application Name] Release.
  • Change the name and then click on Save.

Now we need to talk about the release pipeline a little as unlike the Build Pipeline it is more difficult to have a standard Release pipeline that you can use for all your Power Platform solutions. This is because each solution will be deployed to different environments. Also, we need to reference the build pipeline that is creating the assets that we are going to deploy. We need to reference that pipeline directly in the YAML. I have not found a way to get around that yet. So let us go over the pipeline and explain some of the YAML.

Firstly, the resources statement this is the section of YAML shown below.

The resources statement

In deployment/release pipelines you need to specify the assets that you are going to release. This is done by the resources section as you can see this reference’s the build pipeline which we are giving an alias of api. The source is the name of the build pipeline that creates the resources. Finally, the trigger statement is set to none. Which means that when the build pipeline completes this release process will not trigger. However, we can change that if we wish to.

If you want the release process to trigger on the completion of a build, you can do that. I will explain how in our hint and tips blog post.

So, make sure that the source value is the same name as the build pipeline that we created earlier.

Next let’s talk about the stage section along with the strategy. This is where the release pipelines are a bit different to build pipelines as there are different deployment strategies that you can use. We are not really worried about that for our type of deployment but if you wish to read more then check out this post.

For us we are going to use the runOnce deployment strategy.

Let’s pull out some key sections. Firstly, for the stage we use the name of the environment that we are going to deploy to. In this example that is Production. The keyword dependsOn is important as this is how to order the deployment process so that environments are deployed to in a particular order. In this example Production has no dependencies. That cannot be right, lets show another example with some dependencies.

This dependsOn has Test which means that another stage called Test has to complete before the Production deployment occurs. Also, we have a condition in this example which will check to ensure that all the steps have completed successfully for this stage to execute. There are some additional things that we can do to control the release process which will be discussed later.

Note the template section, along with some parameters. The template uses parameters and we need to provide those via the parameters section so it can execute correctly.

The PowerPlatformTargetEnvironmentName should be set to reference the name of the service connection associated to the environment that we are going to use to deploy the solution to.

Finally, the PowerPlatformSolutionSettingsFileName is a JSON file which is created by the build pipeline and extracts all the environment variables from. But let’s ignore that for now and discuss later.

So, take the example pipeline and remove the stages that you do not need. Make sure you update the PowerPlatformEnvironmentName to the name of your service connection for the environment.

Run the pipeline when you are ready. This normally takes a couple of goes to get right.

When first running the pipeline use the following tip to check if your pipeline is ok.

  • Click on Run
  • Click on Stages to run

If you see an error displayed then examine the error message and fix the pipeline code.

  • Choose the Test environment
  • Click Use selected stages
  • Click Run

Click on the stage to watch it run.

If the pipeline has not run against this environment, you may be asked to authorise it to access the environment.

All being well your release pipeline will have completed successfully and you will now be able to see the Power Platform Solution in your Test Environment.
Screenshot showing the successful deployment into the Test environment.

Conclusion

Now, we have taken you through how to setup build and release pipelines. The result is that we have a way to deploy our solutions to our different Power Platform environments.

In our next post let’s talk about how these the pipelines work before we discuss some different scenarios and options that we can setup to give us control of our deployments.

Photo by Drew Sal on Unsplash

Setting up for Power Platform Dev Ops Pre-requisites


Introduction

This blog post is part of a series of blog posts based on my experiences building a set of Dev Ops processes for deploying Power Platform solutions using Azure Dev Ops.

I recommend starting there if you have not read the first post in the series.

This post will discuss the pre-requisites required to set up Power Platform Dev Ops. Then it will show you how to setup these pre-requisites.

So, let’s get started!

Firstly, the process to deploying Power Platform solutions into an environment relies on a couple of things:

  • An identity to authenticate with the Power Platform environment
  • Access to the Power Platform environment
  • A connection to the Power Platform environment for Azure Dev Ops

The identity that we are going to use is an Azure Active Directory Application. If you do not know what one of these is, then read this. Briefly, it is like a service account and represents an application within Azure which can be given permission to access resources in Microsoft 365 and Microsoft Azure.

I will refer to this Azure AD Application as the Power Platform Deployment Engine. This is the terminology that we use at iThink 365.

Secondly, this identity needs to be able to access the Power Platform environment, so we will discuss the steps to do that.

Finally, our Azure Dev Ops environment that is going to be running the build and release processes needs to be able to connect to the Power Platform environment using the Power Platform Deployment Engine. In Azure Dev Ops this is achieved using a service connection.

Setting up the Power Platform Deployment Engine (Azure Active Directory Application)

To set up the Azure AD Application, do the following: 

  • Choose the Azure Active Directory resource 
  • Click on Application Registrations 
  • Add a new Application Registration, click New Registration 
  • Fill in the details as shown in the screenshot below 
  • Name: Power Platform Deployment Engine 
  • Supported account types: Single Tenant
  • The redirect URL is optional. At iThink 365 we set up it up as our website, https://www.ithink365.co.uk.
  • Click Register when ready 
Steps to setup the Azure AD Application for the Deployment Engine

Next, set up the permissions that the app required: 

  • Browse back to the application 
  • Click API Permissions 
Setting up API Permissions

  • From the API permissions page 
  • Click Add permission 
  • Choose from the right-hand task pane “Dynamics CRM” 
  • Choose delegated permissions 
  • Choose user-impersonation 
  • Click add permission Graphical user interface, application, Teams

Description automatically generated 
  • Add another permission, this time for Microsoft Graph 
  • Find the User group 
  • Choose User.Read 
  • Click Add permission 

Once the permissions are set up then the permissions need to be granted for the tenant using admin consent. 

To achieve this you need an account with the Global Admin role assigned. 

  • From the API permissions screen
  • Click Grant admin consent for [tenant name] 
  • Sign-in and consent to the application. 

The last step is to create a client secret. 

  • Click Certificates and Secrets 
  • Click New Client secret 
  • Fill in a description and set the lifetime for 2 years 
  • Make note of the client secret that has been created as you will need it later.

The Azure AD Application configuration is complete. 

Setting up access to the Power Platform environment

The next step is to give the Power Platform Deployment Engine access to the Power Platform environment.

The process to do this has the following steps:

  • Add an application user to the Power Platform environment.
  • Set permissions for the environment for the application user.

Let’s get started.

To do this do the following: 

  • Click on the Environment name
  • Click Settings
  • Click Users + Permissions to expand
  • Click Application Users
Accessing the application users

From the application user screen click New app user.

  • Click Add an app
  • Search for the Power Platform Deployment Engine app
  • Select the app and click Add App
Add an application user
Search, find the deployment engine and add the application
  • Click security roles
  • Choose System Customizer
  • Click Save
Select the security roles
  • Click Create

The deployment engine now has access to the Power Platform environment. We have given the deployment engine the minimum access that we can however there are times when the deployment engine needs more permission. The time that I have seen more permissions is if security roles are deployed in solutions. If that is the case then give the deployment engine the System Administrator security role.

The setting up of the deployment engine will need to be repeated for each Power Platform environment that we are going to deploy to but also the environment that we are developing our solutions in.

Therefore, repeat the set up process for each of the Power Platform environments.

With all the Power Platform environments setup, the final step is to connect our Azure Dev Ops environment to the Power Platform environment using the deployment engine.

Connect Azure Dev Ops to the Power Platform Environment

The last step is that Azure Dev Ops is connected to the Power Platform environments using our Deployment Engine.

We will make an assumption that you have an Azure Dev Ops Project Collection setup already. You will also need to be an Azure Dev Ops Project Administrator for the project.

  • Browse to your Azure Dev Ops environment.
  • Browse to your project.
  • Click Project Settings.
  • Choose Service connections 
  • Click new service connection 
  • Choose Power Platform 
  • Click Next 
  • Fill in the server URL which is called the Dynamic URL from the Power Platform environment you are connecting to. 
  • See Getting the URL to your Dynamics environment section above 
  • Fill in your tenant id (which is found by going to https://portal.azure.com. Choose Azure AD -> Properties) as the directory id 
  • Fill in the application id for the Power Platform Deployment Engine 
  • Fill in the client secret for the deployment engine which you made note of before. 
  • Fill in the name of the service connection.

We use the following naming convention for our service connections so that it is easy to see the different service connections.

  • Use Power Platform [Release Stage] Environment ([domain.com])
    • e.g. Power Platform Development Environment (dev.ithink365.co.uk)
    • e.g. Power Platform Test Environment (dev.ithink365.co.uk)
    • e.g. Power Platform Test Environment (customer.com)
    • e.g. Power Platform Production Environment (customer.com)
  • Click Save 

Repeat the service connection setup for each Power Platform environment. 

  • Click Save to complete the configuration of the service connection

You will now see the service connection for the Power Platform you have just created.

Repeat the process to connect to all the Power Platform environments that need to be deployed to.

Getting the URL to the Power Platform environment 

To get the URL for your Power Platform environment do the following:

Summary

The steps that we have been through have created all the pre-requisites for deploying Power Platform solutions using Azure Dev Ops.

In the next article, we will go through the process of setting up the build and release pipelines.