DevOps Dataverse ALM using Power Apps CLI: a source centric approach – Part 2

In the Part1 of the blog post we saw how to set up the CDS projects, and also the first Azure DevOps Pipeline which allows us to grab the customizations, extract the content and commit to the github repository (inside a CDS project). In this blog I’ll write about the second pipeline, which I use to build the project and generate the solution. This pipeline doesn’t need any environment, in order to build de solution.

Version

Before we build the solution, we should increment the version. In my case I wanted to take the PCF Version and sync that with the solution version. Until now I’ve seen the implementation of version incrementation using PowerShell. If you prefer this aproach and are looking for an example, you can follow the blogs mentioned in the Part1 of this blog.

I preferred anothed approach. It’s not really easier, but I think I’ve falled in love with the PowerAppsCLI 💜 . I couldn’t resist and tried to use it. Not sure if you’ll like it, or you’ll think I went crazy, but I’m happy that the experiment succeeded.

The “pac” opens a few possibilities to work with version, like:

pac pcf version
pac solution version

And both have the possibility to specify a “–strategy”

pac pcf version --strategy 

It updates the build version of ‘ControlManifest.xml’. Available values are “gittags, filetracking, manifest”. If you want to read more about “version –strategy”, you can find this in my other blog. For my pipeline I’ve decided to use the “manifest” to track the version.

pac pcf version --strategy manifest 

This will search for the ControlManifest.xml and increment the build version.

So 1.0.1 will be changed to 1.0.2

Solution version

Ok, we have the PCF version set. Now I need to set the build version for both CDS projects. For that I used:

pac solution version --patchversion

This allows me to set in the solution version only the latest part. The only problem was, that I had to read the version from the manifest. I wonder if there is a better way.

If the PCF manifest is not incremented, the pcf won’t be updates in your environment. But take care: the major or minor version shouldn’t be changed. Otherwise you’ll see the changes only after removing and replacing the PCF on the form.

Pipeline implementation

There are so many steps, only because I need 4 solutions at the end: PCFOnly, Complete (PCF and Customizing), both in managed and unmanaged version.

1. Install pac CLI and increment version

Disclaimer: I’m an absolute beginner in DevOps and in PowerShell. In case you know better ways for the implementation, please let me know.

This one is a little longer:

And here comes the explanation:

1.1 Install the PowerApps CLI (I used the msi package)

Invoke-WebRequest -Uri https://aka.ms/PowerAppsCLI -OutFile powerapps-cli-1.0.msi
Start-Process powerapps-cli-1.0.msi -ArgumentList "/q" -Wait

& "$env:LOCALAPPDATA\Microsoft\PowerAppsCLI\pac"  install latest

1.2 Increment the PCF manifest version.

& "$env:LOCALAPPDATA\Microsoft\PowerAppsCLI\pac" pcf version -s manifest

1.3 Then read the new patch version, because it’s need for the solution increment

$manifest = [xml](Get-Content "$(Build.SourcesDirectory)/MyProject/ControlManifest.Input.xml")
$controlVersion = [version]$manifest.SelectSingleNode("/manifest/control").version
$patch = $controlVersion.Build
Write-Output $patch

1.4 Then set the solution version

cd "$(Build.SourcesDirectory)\Solution\Complete"
& "$env:LOCALAPPDATA\Microsoft\PowerAppsCLI\pac" solution version -pv $patch
cd "$(Build.SourcesDirectory)\Solution\PCFOnly"
& "$env:LOCALAPPDATA\Microsoft\PowerAppsCLI\pac" solution version -pv $patch

2. Install npm packages

3. Build the solution for my “complete” .cdsproj in release mode

The Build Arguments for release are : /t:build /restore /p:configuration=Release

4. Build the solution for my “complete” .cdsproj in debug mode

This time “/t:build” is enough

5.&6. Repeat step 3 & 4 for the PCFOnly .cdsproj

7. Commit the changes

Since we changed the version, we need to commit

8. Publish the pipeline artifact for the “Complete” cdsproj

We cannot use wildcards, so I took the whole “bin” folder. This way I get the subfolder “Release” and “Debug”

9. Repeat the step 8, but for the PCFOnly cdsproj

This time the artifact will be placed in the “DropControl”.

Each “Drop” folder will contain “Complete.zip” and “Complete_managed.zip” while each “DropControl” will contain PCFOnly.zip and PCFOnly_managed.zip. That’s because the .cdsproj files were changed to generated both managed and unmanaged solutions.