Task to detect if solution exists in environment

[davidjenkins]

THE PROBLEM:

It is often required that solutions be deployed using Azure DevOps Pipelines. Sometimes there are often several iterations or environment rebuilds that must occur before the initial go-live of a solution, meaning that importing the solution into an environment for the first time (or after a rebuild) must use the stage-and-upgrade strategy rather than the import-as-holding strategy. However, subsequent imports into that same environment may require the import-as-holding strategy (e.g. deployment consists of multiple layer solutions or mid-deployment tasks must be carried out before upgrade occurs). However, importing the solution as a holding solution will fail if the solution does not already exist in the environment.

CURRENT LANDSCAPE:

Currently, Microsoft does not provide a task or simple method for detecting if a solution already exists in an environment, and the current Solution Import task will not perform this detection either. It is left to the implementor to find a way around this problem. Running the PAC CLI inside the pipeline is one option (pac solution list), but setting this up and parsing the output is a nuisance and too much effort for some people. We also can't be certain that the format of the CLI output will remain constant, meaning a change in format could break whatever parsing mechanism we assemble.

Third party tools might be another option, but some orgs or not too keen on the idea of granting third party party code access to their environments or repos.

THE ASK:

Any of the following enhancements to the suite Power Platform Build Tools:

• Update the Solution Import task to detect if the solution exists in the target environment, and then fallback to stage-and-upgrade if it does not exist. Similarly, update the Apply Upgrade task to detect if the solution can be upgraded, and if not, then simply continue instead of producing an error.
• Provide a new Solution List task that outputs a list of solutions present in the target environment (in an easy-to-consume format like a JSON dictionary/object) so that the implementor can perform this check easily and set the correct import strategy on the Solution Import task
• Provide a new Get Solution task, with a solution name input, and multiple outputs that match the pac solution list outputs for that single solution
• Provide a new Check If Solution Exists task, with a solution name input, and a solution exists output (true/false)

[larhem]

Hoping for this to be implemented :)

[SiPurdy]

I pretty much concur, although some of the work is already in place.

ADO Pipeline deploying with --stage-and-upgrade true

There is a webapi query to /api/data/v9.2/solutions?$filter=uniquename%20eq%20'%UNIQUENAME%' and the console outputs The solution: '%UNIQUENAME%' is not found in the target Dataverse organization so it does know everything it needs to.

However it then does StageSolution request followed by StageAndUpgradeAsync which hits the issue. Without the --stage-and-update argument a ImportSolutionAsync request is made, which is correct.

So in short, for --stage-and-upgade if the solution exists, it should do StageAndUpgrade, else ImportSolution.

In PAC, there is pack package deploy --solution $solutionFile which handles individual solutions using a runtime built package, but this isn't available in ADO Pipelines tasks.

[parvezghumra]

Agree with this proposal. I currently have a custom PowerShell script executed before an attempted solution import, which detects whether a version of the solution to be attempted is already present in the target environment and if so which version. This script is based on Microsoft.Xrm.Data.PowerShell module

[larhem]

Same here, but using pac cli.(got the idea from some comments on Benedikt Bergmans excellent blog - https://benediktbergmann.eu/2021/08/06/execute-power-apps-cli-in-azure-devops/#comment-3169).

• adding pac cli with the Power Platform Tool Installer (checkbox on that task)
• running pac cli command to check if solution exist in environment:

#Search for solution in solutions in environment
$solutionList = pac solution list | findstr /i $(SolutionName)

# Check if the solution exists by checking the length of the result
$solutionExists = $solutionList.Length -gt 0
# Writing to variable
Write-Output “##vso[task.setvariable variable=solutionExists]$solutionExists”

• Then having one task for upgrade having a "Control option" and setting custom condition to: eq(variables['solutionExists'], 'true')
• And one task for just import without upgrade with same settings, but custom condition is eq(variables['solutionExists'], 'false')

[SiPurdy]

@larhem
How are you handling authentication? pac auth create doesn't have an argument for taking in a connection string, and we use service connections extensively so would use the task to generate the connectionString.

It would work, but it's not ideal from the perspective of having clean pipeline layouts.

[larhem]

Having this in the start of the ps script where secret is connected to variable group.

pac auth create --name someramdomname --applicationId $(AppId) --clientsecret $(Secret) --environment $(Environment) --tenant $(Tenant)

Its not ideal, but the workaround works for us until this is part of the power platform build tools :)