For the creation of a Power Platform Service Connection in Azure DevOps, we need the following information from an Azure AD App Registration:

• Tenant ID
• Application ID
• Client Secret

To completely automate the provisioning of a Power Platform environment and the creation of the associated Power Platform Service Connection in Azure DevOps, we need to be able to automatically generate a new App Registration.

In some cases you could want to automate the activation of the early access to a new major release for a Power Platform environment.

Below we have some information (gathered by our friend David Rivard) that could help us work on that issue:
Here is the request that is sent when you click on the Enable button:
https://admin.powerplatform.microsoft.com/api/environments/{GUID_OF_ENV}/features/October2020Update/enable?geo=Na
*geo=Na must standfor NorthAmerica
**I guess Each update will have there own url (ex. October2020Update, April2021Update) etc..

The tricky part would be to assess when the upgrade process is finished in order to put it in a release pipeline.

By analyzing the request sent by the admin portal I think this could be achieved.
After enabling the feature, this request is sent at regular interval
https://admin.powerplatform.microsoft.com/api/environments/{GUID_OF_ENV}/features?geo=Na

The response gives the status of the upgrade in the AppsUpgradeState property
Upgrade in progress

Upgrade finished

To be able to use a Power Platform environment in your ALM process, we need 3 things (if we want to use service principal authentication):

• a Power Platform environment (obviously)
• an application user on your Power Platform environment
• a Power Platform service connection in your Azure DevOps project

One way to achieve all this is with YAML files.

Other version of the existing issue #9

When we do not need anymore a Power Platform environment integrated with an Azure DevOps project, we have few things to do:

• delete the Power Platform environment
• delete the Power Platform service connection in the Azure DevOps project

Another way to achieve this is by using:

• existing Power Platform for Admins connector to delete the environment
• a custom connector using the Azure DevOps REST API for the management of the service connections

Based on feedbacks, we will update the README.md for setup of the Power Platform ALM Starter Kit to make it easier for people to use it.

Based on the idea presented with the Scaffolding example in the GitHub azure-devops-cli-extension project, it could be interesting to initiate a Power Platform Azure DevOps project template.

In a first version I imagine having the things below:

• creation of a new project in a targeted Azure DevOps organization
• creation of the repository
• import basic YAML files for the management of the ALM of Power Platform solutions from a public repository (this one?)
• create the pipelines based on the YAML files imported
• generate Power Platform service connections for existing Power Platform environments based on a configuration file to update

The documentation provided in the PP ALM Starter Kit should describe a recommended environment structure.

When we do not need anymore a Power Platform environment integrated with an Azure DevOps project, we have few things to do:

• delete the Power Platform environment
• delete the Power Platform service connection in the Azure DevOps project

These points can be address using YAML files.

The Documentation of the PP ALM Starter Kit should describe missing elements in the Power Platform Build Tools for Azure DevOps as well as describe workarounds.

Those are for example:

• Applying Solution Upgrades is not possible
• Installing additional languages to JIT environments
• Installing early access features to JIT environments

Other version of the existing issue #8

To be able to use a Power Platform environment in your ALM process, we need 3 things (if we want to use service principal authentication):

• a Power Platform environment (obviously)
• an application user on your Power Platform environment
• a Power Platform service connection in your Azure DevOps project

Another way to achieve this is by using:

• existing connectors of the Power Platform (ex: Power Platform for Admins for the creation of the environment)
• a custom connector using the Azure DevOps REST API for the management of the service connections

I am still looking a good way create an application user in the new Power Platform environment, but it sure can be done using a UI Flow.

The Documentation of the PP ALM Starter Kit should describe a basic ALM process.

Is your feature request related to a problem? Please describe.
We don't have an easy way to find the merge of the first milestone.

Describe the solution you'd like
Add a tag v0.1 to the following commit 5715d26.

Describe alternatives you've considered
Create a GitHub release, but I don't think it is the good choice because we don't really have artifacts to share.

Additional context
Not applicable.

One way to simplify the provisioning of a Power Platform environment could be to reduce the number of input variables needed for the create-powerplatform-environment-and-service-endpoint pipeline.

I think that a template file in JSON could be a good way to manage the properties of the Power Platform environment.
This template file would be then consumed by the create-powerplatform-environment-and-service-endpoint pipeline (path to the file provided as a variable).

Automate the provisioning of a Power Platform environment is one thing, but by default (with the Create Environment action in the Power Platform Build Tools extension for Azure DevOps) you can only specify one language.

It seems that the following solution (information provided by our friend David Rivard) could help us go further on this part:
https://github.com/seanmcne/Microsoft.Xrm.Data.PowerShell

Function to try: 'Enable-CrmLanguagePack'

----EXAMPLE POWERSHELL SCRIPT---------
Param(
[string]$connectionstring
)

Write-Output "Installing Microsoft.Xrm.Data.PowerShell"
Install-Module -Name Microsoft.Xrm.Data.PowerShell -Scope CurrentUser -Force

#Write-Output "Installing Microsoft.CrmSdk.XrmTooling.CrmConnector.PowerShell"
#Install-Package -Name Microsoft.CrmSdk.XrmTooling.CrmConnector.PowerShell -Scope CurrentUser -Force

Write-Output "Connecting to CRM"
$conn = Get-CrmConnection -Verbose -ConnectionString "$($connectionstring)"

Write-Output "Fetching organizationid"
$organizationid = (Get-CrmRecords -EntityLogicalName organization -conn $conn -Fields organizationid).CrmRecords[0].organizationid

Write-Output "Changing setting on organization: $($organizationid)"

Set-CrmRecord -EntityLogicalName organization -conn $conn -Id $organizationid -Fields @{"isautosaveenabled"= $false; "isexternalsearchindexenabled"= $true; "useskypeprotocol"=$false}

$org = Get-CrmRecord -EntityLogicalName organization -conn $conn -Id $organizationid -Fields isautosaveenabled,isexternalsearchindexenabled,useskypeprotocol

Running export solution to git Im getting the following:

This is the task that fails:
task: microsoft-IsvExpTools.PowerPlatform-BuildTools.tool-installer.PowerPlatformToolInstaller@0
displayName: 'Install Power Platform Build Tools'

I think my ALM version is v1.183.0 (from devops-tasks-schema.json)
It is several version behind, but was working fine

Any ideas?

Starting: Install Power Platform Build Tools

Task : Power Platform Tool Installer
Description : Power Platform Tool Installer
Version : 0.0.77
Author : Microsoft
Help : More Info

Name Version Source Summary

nuget 2.8.5.208 https://onege.../ NuGet provider for the OneGet meta-package manager
##[error]The specified module 'PackageManagement' with version '1.4.7' was not loaded because no valid module file was found in any module directory.
Finishing: Install Power Platform Build Tools

The Starter Kit should include an ap to handle deployments to all the different environments. The app should trigger pipelines in Azure DevOps

The PP ALM Starter Kit should include YAML files to make it easier for users to create a basic ALM process with Azure DevOps pipelines

The ALM Starter Kit could describe possible additions to a basic ALM process to make it more advanced.

Those could for example be

• automated Tests
  -- Unit
  -- Integration
  -- UI
• Checks against the Solution Checker

Is your feature request related to a problem? Please describe.
We don't have an easy way to follow what have been done in the different versions of the "solution" in this repository.

Describe the solution you'd like
Add a CHANGELOG.md file based on the following example: CHANGELOG.md

• Replace the existing template for bugs in markdown in the .github/ISSUE_TEMPLATE folder by an issue form definition in YAML
• Create a template chooser with redirections to Ideas discussion channel for ideas and Q&A discussion channel for questions
• Disable blank issues in the template chooser configuration (blank_issues_enabled: false)

The Documentation of the PP ALM Starter Kit should describe why ALM is important for every project.