Deployment Stacks support

[StefanIvemo]

Talking to the ARM Deployments team it is clear that Deployment Stacks are the future of deployments. Can we please get Deployment Stacks support in AzOps?

[daltondhcp]

Thank you for raising this. This is indeed something we plan to explore, as it offers significant benefits for managing resources at scale. However, given the constraints and the need to align with existing AzOps use cases, we are considering the following initial implementation approach:

• Deployment stacks will be limited to custom templates. Auto-generated templates from AzOps pull will not use the deployment stack model.
• A .deploymentStack configuration file will be introduced per stack enabled scope. This file will:
  • Define whether deployment stacks are enabled for a given scope.
  • Specify stack settings for the scope, such as ActionOnUnmanage, DenySettingsMode, DenySettingsExcludedPrincipal, and DenySettingsExcludedAction.
  • If interesting, we could explore exposing this as a global setting as well.

MG root/
├── Intermediate Root MG/
│   ├── .deploymentStack
│   ├── metropolis.bicep
│   ├── LZ/
│   │   ├── Sub 1/
│   │   │   ├── .deploymentStack
│   │   │   ├── e2e-aks.bicep
│   │   │   ├── ai-foundry.bicep
│   │   │   ├── RG 1/
│   │   │   └── RG 2/
│   │   │       ├── .deploymentStack
│   │   │       └── workload.bicep
│   │   ├── Sub 2/
│   │   │   ├── .deploymentStack
│   │   │   ├── stuff.bicep
│   │   │   ├── RG 1/
│   │   │   └── RG 2/
│   │   │       ├── .deploymentStack
│   │   │       └── workload.bicep
│   ├── Platform/
│   │   ├── Sub 3/
│   │   └── Sub 4/

• Each deployment stack will correspond 1:1 with a Bicep file in a deployment-stack-enabled scope.

• Stack names will be deterministically generated based on the file name and scope.

• To prevent unintended deployments, Bicep modules should either reside outside the stack-managed folder or be pulled from a Bicep registry (similar to how it works today)

• Deleting a file from a stack-managed folder will, by default, trigger the removal of the associated stack.

We welcome your feedback and thoughts on this approach.

[SimonWahlin]

I initially imagined putting the stack configuration in a template.stack.json and mapping that to a template using the same logic as with mapping a template to a parameters file. Basically if there is a .bicep and a corresponding <template.stack.json>, convert the latter to a hashtable and splat it on the deployment command.

Reading this I see the benefit of simplicity having a .deploymentStack being applied to a full scope, which I assume is not inherited to any child scopes?

I can however imagine a few scenarios where I might want to specify different stack configuration for different stacks in the same scope:

1. I can see deploying multiple stacks on for example a subscription or managementgroup scope where each stack will have different sets of DenySettingsExcludedActions depending on the resources the stack is deploying. Sure, we can add 200 actions to the list so we can potentially add any excluded action needed by any stack in a scope to one big list, but there might be scaling issues as well as confusion regarding which stack that actually needs which action.
2. When deploying stacks on the MG scope, I might want to add different ExcludedPrincipals based on which subscription the stack is deploying into. Might vary depending on the environment of the subscription or the owner of the subscription.
3. I might not want or need to use the same DenySettingsMode for all deployments. I'm totally fine with defaulting to stacks for any template in a scope, but I might not need or even want to use the same DenySettingsMode on all stacks. Same thing goes for DenySettingsApplyToChildScopes which also might require different values for different stacks deployed in the same scope.
4. If there is a certain template that for some reason doesn't work as expected when using stacks, it would be nice to be able to opt-out of using stacks for that specific template.

[daltondhcp]

Thanks for the input - really appreciate the suggestion! I don’t think it has to be mutually exclusive.

How about this:

• .deploymentStacks - Enables deployment stacks for all templates in a specific scope, without inheritance.
• templatename.stack.json - Enables stack deployment for a specific template, using the settings defined in the file.
• If both .deploymentStacks and templatename.stack.json exist at the same scope, the per-template settings will take precedence when deploying that specific stack.
• In scenarios where there's a 1:1 mapping between stack settings and templates, you can exclude templates simply by omitting the .stack.json file for them. If you're using only .deploymentStacks, exclusions would be managed directly within that file.

[SimonWahlin]

Sounds like a great solution!

What will the schema for .deploymentStacks be?
If it will be in json or yaml format, maybe it makes sense to use .deploymentStacks.json/yaml to get IDE formatting help

[StefanIvemo]

Thanks for the input - really appreciate the suggestion! I don’t think it has to be mutually exclusive.

How about this:

• .deploymentStacks - Enables deployment stacks for all templates in a specific scope, without inheritance.
• templatename.stack.json - Enables stack deployment for a specific template, using the settings defined in the file.
• If both .deploymentStacks and templatename.stack.json exist at the same scope, the per-template settings will take precedence when deploying that specific stack.
• In scenarios where there's a 1:1 mapping between stack settings and templates, you can exclude templates simply by omitting the .stack.json file for them. If you're using only .deploymentStacks, exclusions would be managed directly within that file.

This sounds good to me!