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:
Introduction to Power Platform Dev Ops post (this post)
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.
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.
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.
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.
Doy's Microsoft 365 and Azure Dev Blog 