fix: AppServicePlan - SKU selection improvements

[tsc-buddy]

Description

Provides improvements to simplify the selection of SKUs for App Service Plans by relying on the RP to provide the values for 'tier', 'family' and 'size' properties based on the 'name' provided. Logic adjusted on ZR param to accommodate the change also.

Closes #1506

Pipeline Reference

Pipeline

Type of Change

• Update to CI Environment or utlities (Non-module effecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

Note

This label was added as per ITA06.

[microsoft-github-policy-service]

Note

The "Type: AVM 🅰️ ✌️ Ⓜ️" label was added as per ITA08BCP.

[tsc-buddy]

@Azure/avm-core-team-technical-bicep - Can you provide some guidance on whether the change to the way the SKU parameter now works, warrants a bump in version or not? I was unsure, so didn't adjust it, but I'm mindful the way the SKU was provided has change from an object with 5 properties to, two separate spring params and others being handled by the RP. Technically breaking peoples current approach to the usage of the module, but not the provisioned resources.

[cloudchristoph]

@Azure/avm-core-team-technical-bicep - Can you provide some guidance on whether the change to the way the SKU parameter now works, warrants a bump in version or not? I was unsure, so didn't adjust it, but I'm mindful the way the SKU was provided has change from an object with 5 properties to, two separate spring params and others being handled by the RP. Technically breaking peoples current approach to the usage of the module, but not the provisioned resources.

Just my 2 cents:

Since you are changing the "interface" to the module - including new required parameters - this should definitely be a new version.

The people who previously used the module in the current version do not set the "skuCapacity" parameter, for example. Their template will then become invalid, even if they didn't change the module version..

[AlexanderSehr]

@Azure/avm-core-team-technical-bicep - Can you provide some guidance on whether the change to the way the SKU parameter now works, warrants a bump in version or not? I was unsure, so didn't adjust it, but I'm mindful the way the SKU was provided has change from an object with 5 properties to, two separate spring params and others being handled by the RP. Technically breaking peoples current approach to the usage of the module, but not the provisioned resources.

Just my 2 cents:

Since you are changing the "interface" to the module - including new required parameters - this should definitely be a new version.

The people who previously used the module in the current version do not set the "skuCapacity" parameter, for example. Their template will then become invalid, even if they didn't change the module version..

100% correct @cloudchristoph. As we're still in the 'pre 1.0' phase, plese update the module's version to the next minor @tsc-buddy.

That being said and for context, @cloudchristoph, a change to a module always results in a new version / we never overwrite a current one. But we still want to adhere semver (especially from 1.0 onwards), so it remains a valid ask to explicitely bump up the version (to in this case at least a new minor).

[AlexanderSehr]

Please bump the version in the version.json file as per the dicsussion in the PR's comments.

[tsc-buddy]

Please bump the version in the version.json file as per the dicsussion in the PR's comments.

All done. Thanks @AlexanderSehr