[ALM Accelerator - Feature]: Download & Import external Solutions

megel commented 2 years ago

Is your feature request related to a problem? Please describe.

Importing external solutions is currently a highly manual task for customers. Its not about the initial import, you need also to frequently update solutions by importing newer solution versions.

The AA4PP is a great tool to automate and document such a process. Especially, when you want to run an automated solution transfer from VAL -> TEST -> PROD environments. Furthermore, with AA4PP you can prepare and specify the deployment settings for the target environments.

Describe the solution you'd like

Download & Import external Solutions

To keep it simple, an external solution can downloaded as Solution Package from:

URL (Storage Account)
Artifact Feed in Azure DevOps

A Solution Package must contain:

Solution-zip (managed or/and unmanaged)
Deployment Parameters as JSON (similar to AA4PP pipeline variable Data)

The solution must be extracted after downloading the solution package either from unmanaged or managed solution.zip. A change in the included solution manifest is necessary, when only a managed solution is included. This is because the solution.zip must be unpacked for the Repo by using PAC solution unpack ... in pipelines. Afterwards, the solution is stored as source code in a configured repository from AA4PP. From this point, the solution is able to be imported as managed solution into AA4PP environments (VAL, TEST, PROD, ...) by using the deployment settings.

AA4PP Piplenes

The implementation needs a new pipeline in template repository download-solution-to-git.yml, which:

download and extract the solution package (solution zip-file(s) and deployment settings)
optional change solution manifest in solution_managed.zip, when unmanaged solution is not delivered
extract the included solution zip-files similar to export.solution-to-git.yml
extract the included deployment setting similar to export.solution-to-git.yml
import deployment setting and delivered solution version into Dataverse for the external solution (not present in DEV environments)
store solution source code and deployment setting similar to export.solution-to-git.yml

Finally, this pipeline can also create a PR from import branch into the solution branch to trigger an automated solution import into VAL. This could help to collect deployment information in AA4PP PowerApp.

CoE CLI

The CoE CLI must be able to trigger the download-and-import solution. The signature can be:

Usage: coe alm import [options]

Import or Update an external solution in an existing Application Branch

Options:
  -u, --url <url>                  Download url for external solution
  -o, --devOpsOrganization <name>  The Azure DevOps Organization name
  -p, --project <name>             The Azure DevOps name
  -r, --repository <name>          The Azure DevOps name
  --pipelineRepository <name>      The Azure DevOps pipelines templates repository name (default: "pipelines")
  -d, --destination <name>         The branch to create
  --source <name>                  The source branch to copy from
  --source-import <name>            The import branch name
  -s, --settings <namevalues>      Optional settings
  -a, --accessToken <name>         Access Token for Azure DevOps
  -t, --template <name>            Additional deployment template for an additional environment
  -l, --log <log>                  The log level (choices: "error", "warn", "info", "verbose", "debug", default:
                                   ["info"])
  -h, --help                       display help for command

The command will run the pipeline download-solution-to-git.yml with provided information as variables.

AA4PP PowerApp

A maker must be able to setup and manage external solutions in AA4PP. Furthermore he must invoke the download for this solutions. Afterwards he is able to specify deployment information - maybe based on VAL environment - for external solutions. Finally, the maker can release the imported solution by finishing the PR into TEST and creating a PR into PROD.

@mikefactorial what do you think about my idea?

Describe alternatives you've considered

Import and configure each solution manually in each environment.

Additional context?

No response

AB#1281

mikefactorial commented 2 years ago

@megel thanks for raising this and for putting all the thought into it. I agree that this would be a very useful feature. Something that we've needed internally for a while, but the import process hasn't gotten a lot of attention recently. Good timing to rethink some of this. I'll bring this up with the team today at our standup to get feedback.

megel commented 2 years ago

@mikefactorial feel free to include me into your discussion, its something what each Microsoft Customer & Partner needs as well.

sdhsynsci commented 1 year ago

We need this as well. The above feature would be extremely helpful in this scenario because a given release of the Client product would be packaged with the proper release of product and client solutions. In the meantime, do you have a suggestion? We are currently building release pipelines to try and keep everything updated across all environments but are struggling with version control to match the correct base solution version, correct product version, with a given client build. We have a set of base solutions that products solutions are built from, and then the product solutions become the base for our client solutions. One approach is just always using the most current builds and hope it does not break stuff too often and if it does make quick fixes. The other approach is manual tracking or a set of AzDo variables to track what version is linked in a given scenario [Base, Product, Client, and Val, Test, Prod envrionment].

microsoft / coe-starter-kit