Introduction

Photo by Paul Hanaoka 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.

This post discusses how to use the build and release pipelines to set up your environment variables within your solutions. If you remember the build and release pipelines can be found in the following GitHub repository.

In solutions, the settings for the application are configured using Environment Variables. For example, we use a set of administration email addresses to send failure messages when a Power Automate flow fails.

When using Dev Ops processes then without this step it can be a bit of a pain to deploy the solutions as each time you deploy then the environment variables are generally not set correctly and therefore the application that you have built does not work.

The question is, how do you configure these environment variables with Dev Ops Processes?

Fortunately, with the Power Apps CLI and the Dev Ops pipelines, we can configure these values easily. So let’s show you how to do it.

Using Dev Ops to set environment variables

As mentioned in the previous posts, the build pipeline extracts a settings file from the solution using the Power Apps CLI or PAC command. This settings file is a JSON file which looks something like the one below.

{
  "EnvironmentVariables": [
    {
      "SchemaName": "i365_AdminEmail",
      "Value": ""
    },
    {
      "SchemaName": "i365_TGPSharePointIncidentsList",
      "Value": ""
    },
    {
      "SchemaName": "i365_TGPSharePointSite",
      "Value": ""
    }
  ],
  "ConnectionReferences": [
    {
      "LogicalName": "i365_Office365OutlookManagementSystem",
      "ConnectionId": "",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365"
    },
    {
      "LogicalName": "i365_Office365UsersManagementSystem",
      "ConnectionId": "",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_office365users"
    },
    {
      "LogicalName": "i365_SharePointManagementSystem",
      "ConnectionId": "",
      "ConnectorId": "/providers/Microsoft.PowerApps/apis/shared_sharepointonline"
    }
  ]
}

What we need to do to be able to configure our settings, is take a copy of this settings file and add some tokens to it. These tokens will be replaced by the release process and the settings file will be used to configure the environment variables when the solution is deployed.

So, let’s do that.

First of all, I am making a presumption that your build pipeline is working and creating your solution. As part of the build process, a set of artefacts are associated with the build. One of the artefacts is the settings-test.json file.

Take a copy of that file from the artefacts as shown above and download it to your machine.

Next, we replace the values with tokens, tokens should be in the form of __[SettingName]__.

For example:

{       "SchemaName": "i365_AdminEmail",       "Value": ""     }

becomes

{       "SchemaName": "i365_AdminEmail",       "Value": "__AdminEmail__"     }

We replace each of the values with the tokens as shown above. Once there is an updated settings file, this file then needs to be uploaded into our git repository so that we can use it in the build and release process.

One of the build pipeline tasks will associate it as a build artefact. This is if it has a file name with “**settings*.json” in it. The naming convention that I use is [company]-[applicationname]-solution-settings.json. This file should be added to your GitHub repository within the folder with the rest of your content for your Power App.

Setting up the Build Variables for token substitution

Once we have the settings.json file with the tokens in place we need to define the settings that will be used to replace the tokens.

For our variable groups, we use the following naming convention:

[company]-[appname]-[environmentname]

e.g. i365-holidayapp-dev

To set up a new variable group, click on the “Variable Group” button as shown below.

Provide the name and description for the variable group.

For each setting that you have defined as a token in your JSON settings file then create a variable with the same name. So for example __AdminEmail__ becomes AdminEmail.

Once you have created variables for each setting you should have something like the screenshot below.

Now that our build variables have been created, repeat for each of your environments, such as test, uat, and production. Remember to save the variables after you have created them!

Referencing the Variable Groups in our Release Pipelines

With our variable groups setup, there is one more job that needs to be done. The release pipelines need to be told about them. The way that I do this is using a YML variable template. This looks something like this:

# This is used to add references to a Azure Dev Ops Variable Group Configuration.
# Replace [customer] with the abbrevation used for the customer.
# Replace [app] with the name of the application.
variables:
- group: [customer]-[app]-dev

An example is shown below.

# Example Variable Group
variables:
- group: leave-app-test

Notice the line variables and the subsequent line, ' - group‘. This is used to reference the variable group that we have just created. The YAML file is created for each environment and I use the naming convention of [company]-[appname]-[environment]-variables.yml.

With these YAML files created and put into your Git repository. There is one last step and that is to reference the YAML file in our release pipeline. This is shown below:

Please note the fact that the template is using a relative path. There is an issue with Azure Dev Ops when referencing YAML variable template files which are not within a folder that is under the release pipeline file. Of course, the variable template file can be in the same directory but not in a directory above the current folder.

Each of the variable templates should be set up for each of the environments that we are deploying to.

Testing the deployment

So with everything now in place, let’s test the deployment and show how it will work.

We will run a new build so that we have the reference to the new settings file that is part of the assets.

During the release process, the Setup Power Platform Configuration task will run. This task will look through files with file names that end *settings.json and replace the tokens with the build variable values.

Now, the JSON file has been set with the required values it is next used to with the solution deployment to set the environment variables in our solution.

The task below configures the environment variables.

Once the release has been completed then the environment variables will have been set. One thing to say is that if you do not set the environment variables correctly then the environment variables will be set to blank!

To check the environment variable that has been set, go into the Power Platform, choose the environment that you have deployed to. Finally, open the default environment and then open up the environment variable and you will see the value set as shown below.

Conclusion

Hopefully, we have shown you how to use the Azure Dev Ops Build and Release pipelines to set up releasing your Power Platform solutions and set the environment variables from Azure Dev Ops.

In the next blog post, I aim to highlight some more tips and tricks that I use when working with Power Platform and using these Dev Ops processes to streamline our releases.

Thanks for reading, just to say I would appreciate any feedback you have, good or bad. I am particularly interested in seeing how people got on implementing the pipelines and what issues you have hit.

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 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.