In the previous post, we setup a Service Principal that allowed DevOps to access and perform actions in an Power Platform environment.
In this article, we'll actually utilise the service principal to export a solution and then save it into a DevOps repo.
- You need a Power Platform environment with a solution you'd like to export. Your solution can be whatever you want. To make it very simple , I've just created a model driven app with one table that stores zoo animals.
- You need a DevOps project with a repo you'd like the solution to be saved into.
- You need a service principal with access to the Power Platform environment (see here)
Setting up your repo
Just a few things that's important after you've set up your repo
Provide the required permissions
First, you need to give your Build Service Contribute permission. This is to allow the pipeline to actually make changes to the repo. You can do this at Project Settings -> Repositories
Limit merge types on the main branch
Secondly, you should limit merge types which will prevent anyone from committing to the main branch without a PR. Admittedly this is optional, but I still would recommend doing it. I normally recommend doing it on all your repos not just this one, but it's more important here because the pipeline will be doing the committing and you don't want to accidentally commit to the main branch without going through your required PR approval process.
Create a feature branch
Create your first Feature branch to start off with. This is the branch the pipeline will save the solution to. Based on your git branch strategy, it may be the only one you use or you may choose to have a new one for each commit.
Creating the Pipeline
Now that we have all our prerequisites, we can start building our pipeline.
Go to Pipelines -> New Pipelines and follow the prompts.
Configuring your pipeline
Allow OAuth token
You'll need to allow this because one of the later steps will require you to run the some powershell which'll need this token.
Install the Power Platform Build Tools extension
This'll only appear if your DevOps organisation has not installed it yet. If you type "Power" into the search bar and you see this option, then go ahead and get this extension from the marketplace for your DevOps organisation. You'll only need to do this for the first pipeline you build.
Add the steps
DevOps pipelines runs a series of operations which is defined in a list of ordered steps. Each time the pipeline is triggered, a container is created on an agent in the agent pool and once it finishes running, the container is destroyed.
To add a step, you add the + sign and find the step
For this pipeline, these will be the steps
Power Platform Tool Installer
This installs the power platform tools on the container so that we can run the rest of the operations
This step will go into Power Platform environment request the solution be exported and then saved in an output folder.
For our purposes, I'll specify the Service Principal in the Service Connection which will tell the pipeline where the Power Platform environment is as well as give it access.
I need to also specify the solution I want to export and an output location which I've put as "$(Build.ArtifactStagingDirectory)\$(BuildFolder)\Drop\Solution.zip" - this is a folder inside my container that I'll reference in the next step.
When you export a Power Platform solution, you get a zip file. Running unpack will extract the zip into a directory with a number of mainly xml files that define the solution.
For our purposes, I need to specify the input file which should be the same as the output file in the last step. Then I need to specify where in the repo to save to - and I've selected the Solutions folder in the repo.
So far, we've exported the solution, unpacked the content into the container on the agent running the pipeline. The last step is push these changes over into DevOps and to do that, we need to run a Powershell script that runs a few git commands.
Click here for the gist but I'll run through what this code does.
git config --global user.email "firstname.lastname@example.org" git config --global user.name "Wai"
The credentials you'll be making your commit as
git switch $(Build.SourceBranchName) git add -A git commit -m "changes exported from dev"
Switching over to the branch you've specified (by default, we've selected the feature branch), adding all the files and making a commit with description.
git push https://$env:SYSTEM_ACCESSTOKEN@dev.azure.com/wai0211/TestProj/_git/Zoo
Pushes the code to your DevOps repo. See here for what
env:SYSTEM_ACCESSTOKEN does but it's an authentication token for the build service. This is why in the prereq. you needed to enable the Contribute permission and why we needed to allow scripts to access the oauth token
Running your pipeline
Now the pipeline has been built, you should be able to run it. This will run through all the steps.
By default, we've set up to run the pipeline against the "Feature" branch but depending on how you work you may want to have to have another branch here so feel free to change this before running the pipeline.
Creating a PR
If your pipeline is successful, you should be able to navigate to Repo, switch to the Feature branch and see the changes
Click on Create new PR Request to get this merged into master.
You should be able to see all the changes. As this is my first commit, there's 21 changes - but later on, as you run the pipeline again, you should only be able to see the differences.
Hit Create, and follow your standard PR approval process to merge this into main.
What we've done in this post is create an automated way to get your changes in your Power Platform environment pushed into source control.
The workflow is that you make the changes you want into the solution, run the pipeline, this'll export the solution and unpack the code into a feature branch.
Then you create a PR to merge this feature branch into your main branch once you're happy with it.
In an upcoming post, I will document how to use DevOps - once you've done the merging - to import the code in your main branch into another environment.
*Update - please see this post for how to autoincrement the version number of your solution on each export.
Top comments (0)