Improve subscription deployment's management group id detection

[SenthuranSivananthan]

When subscriptions are configured through the subscription-ci pipeline, the management group id is inferred by the folder structure where the subscription's parameters JSON file is located.

For example:

• FullPath = CanadaESLZ-main/pubsec/LandingZones/Prod/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx_generic-subscription.json
• RelativePath = CanadaESLZ-main/pubsec/LandingZones/Prod/
• MgmtGroup = pubsecLandingZonesProd

Notice that we've taken the relative path and removed the parent folder CanadaESLZ-main/, then removed the / to create the management group id. We chose this path so that long folder paths does not hit any folder path limits.

This approach works along as as customers use the management group id of the parent as the prefix. For example:

   pubsec
    - pubsecLandingZones
       - pubSecLandingZonesProd   

But it now longer works when the management group ids are customized to remove the prefixes. To support the scenario where the management group ids does not include the prefix of the parent management group, I propose the following changes:

1. Add a new parameter to common.yml: generateSubscriptionManagementGroupIdFromFolderHierarchy with values of either true or false. Default value = true so respect the current implementation.

2. Update .pipelines/templates/jobs/deploy-subscription.yml so that this flag is used when determining the management group.

Example:

Folder Structure:

  pubsec
    \ LandingZones
      \ Prod

• When true: current implementation. Output will be pubsecLandingZonesProd
• When false: use the folder name of the subscription JSON. Output will be Prod

[SenthuranSivananthan]

A possible solution using enumerator instead of boolean. This allows for different schemes in the future.

#!/bin/bash

readarray -t dparts < <(echo "CanadaESLZ-poc/pubsec/LandingZones/DevTest/4f9f8765-911a-4a6d-af60-4bc0473268c0_generic-subscription_canadacentral.json" | tr "/" "\n")

generateSubscriptionManagementGroupIdUsing='FolderName'
#generateSubscriptionManagementGroupIdUsing='FolderHierarchy'

echo $generateSubscriptionManagementGroupIdUsing

case $generateSubscriptionManagementGroupIdUsing in
 FolderName)
  echo 'By folder name: ' ${dparts[@]:${#dparts[@]}-2:1}
  ;;
 *)
  echo 'By hierarchy: ' ${dparts[@]:1:${#dparts[@]}-2}
  ;;
esac

When:

• FolderName: DevTest
• FolderHierarchy: pubsecLandingZonesDevTest

[skeeler]

@SenthuranSivananthan the script logic already handles flattening the structure - both pre and post MG hierarchy configuration improvements. Basically, it takes the folder elements from the full path between the base subscription config folder (config/subscriptions/DevOpsOrg-Branch), joins them together, and uses that as the target management group id. So for example, in our legacy structure where we specified only the MG id in structure.bicep, we'd have an MG with id pubsecLandingZonesDevTest. We would then store the subscription JSON config in the path pubsec/LandingZones/DevTest, however we could also just as easily store it in the folder pubsecLandingZonesDevTest. For that matter (going crazy the other way) we could even store it in this path: pubsec/L/a/n/d/i/n/g/Z/o/n/e/s/DevTest, which we wouldn't do because what would be the point, but just to show the flexibility of the existing script logic both ways. With the upcoming MG hierarchy enhancement (structure in config + ability to specify both the id and the name of each management group), we have the ability through configuration to make the MG id values anything we want, and can create whatever folder structure we want for the subscription JSON config files.

To summarize, existing script logic supports either nested folder or flat folder locations for the subscription JSON config files, so I think we can close this issue without code changes unless I'm not understanding the ask.

[skeeler]

Converting to a documentation issue.

[SenthuranSivananthan]

I see your point. I think we can document as:

• Scenario 1: If a customer chooses to prefix their management group names based on the parent's name, then they can create MG folders in config/subscription without the prefix at each level. This is the current implementation where we would automatically concatenate the folder hierarchy to generate the target MG name.

• Scenario 2: If a customer choses to not use the prefix, then they can create folders at the config/subscription level without any nested folders. This would essentially by pass the concatenation logic we have in place to support the first scenario.

[skeeler]

I'd like us to make the following points clear in the doc enhancements:

• The base location of the sub-guid.json files is configurable in the common.yml (and overridable in environment configuration files) using the subscriptionsPathFromRoot setting. By default it is set to config/subscriptions.
• The relative location of a sub-guid.json file under that baes location is used to form the management group id where the subscription will be located under. Formation is done by joining each part of the relative subfolder name together.
• Examples:
  • config/subscriptions/myorg/Platform/Management/sub-guid.json would form the management group id myorgPlatformManagement
  • config/subscriptions/myorgPlatformManagement/sub-guid.json would also form the management group id myorgPlatformManagement.
• While you can use whatever folder/subfolder hierarch you like (splitting the management group id into as many or few subfolders as desired), the following are recommended:
  • Use a naming convention for management group ids that includes a prefix matching the parent management group.
  • Use a consistent subfolder representation, one of:
    • use a single level of subfolders specifying the full management group id of each folder
    • create a nested series of subfolders, with each level corresponding to a notional level in your management group hierarchy