AzOps Shared/Central parameters support

This issue is a split from #831

Ability to associate/import/refence multiple parameter files into one outcome.

A fair amount of parameters will be shared by customers as well, which could lead to duplication among the parameter files. However, the Bicep community is already working on parameter imports in Azure/bicep#12019.

Dec 04 '23 10:12 Jefajers

A cascading style will be nice. So you can inherit from a more general bicepparameter file and still have the ability to overrule an imported parameter. Like the union() function currently works. The last written value survives.

Feb 07 '24 13:02 schaijkw

Hello @Jefajers,

Extendable parameter files became available as a preview feature in Bicep some time ago. I wonder if we should begin discussing how AzOps could support this new Bicep feature?

For reference on my thoughts, we are using these AzOps settings:

"AzOps": {
  "Core.AllowMultipleTemplateParameterFiles": true,
  "Core.DeployAllMultipleTemplateParameterFiles": true,
  "Core.ParallelDeployMultipleTemplateParameterFiles": true,
  "Core.MultipleTemplateParameterFileSuffix": ".\\w+"
}

Some thoughts on my end:

If I try to use extendable parameter files today, AzOps attempts to locate a template file to associate with my generic parameter files, hence failing the deployment. Example:
```
customer.bicep
customer.one.bicepparam
customer.two.bicepparam
westeurope.01.bicepparam
```
Where customer.one.bicepparam and customer.two.bicepparam both extend from westeurope.01.bicepparam as such:
```
using 'customer.bicep'
extends 'westeurope.01.bicepparam'

param ...
```
This fails, rather expectedly, with:

Did NOT find template for parameters root/mg (00000000-0000-0000-0000-000000000000)/sub (00000000-0000-0000-0000-000000000000)/westeurope.01.bicepparam
Currently, the association between bicepparam files and template files is based on naming of the files as well as the configuration Core.MultipleTemplateParameterFileSuffix. However, bicepparam files have a using statement that defines the association to the template. Perhaps it would be possible to utilize that instead? Then it would also support generic bicepparam files out of the box, since they specify using none, and hence they shouldn't be deployed.
- In extension to this point, perhaps a first step could be to not locate template files for bicepparam files with using none.
And then onto the more complex stuff. Let's say that I have a number of bicepparam files, that extend each other in a chain:
```
// westeurope.bicepparam
using none
param location = 'westeurope'
...
```
```
// westeurope.01.bicepparam
using none
extends 'westeurope.bicepparam'
param instance = '01'
...
```
```
// customer.one.bicepparam
using 'customer.bicep'
extends 'westeurope.01.bicepparam'
param customerName = 'azops'
...
```
If I were to make a change to westeurope.bicepparam, I would actually expect AzOps to redeploy the customer.bicep template for every customer.x.bicepparam file that extends (transitively) from westeurope.bicepparam.

We could probably accept a solution that requires all bicepparam files and templates to be in the same directory, but a solution that is capable of letting bicepparam files extend from files in parent directories would be optimal. Extending from bicepparam files in sibling directories seems like a mistake in my opinion, which could lead to unexpected behaviour.

I have also heard talk from the Bicep community about a proposal for a special type of "deployment file" that can specify things like what template to deploy, which parameter file(s) to use, settings for deployment stacks, etc. Right before the community call next week, my team is going to have a chat with some of the Bicep maintainers about bicepparam files, so perhaps we can find some synergies between Bicep and AzOps as part of that.

Sep 27 '24 07:09 Xitric

@Xitric, lets sync up after your meetup with Bicep maintainers 👍 and take it from there as we aim to incorporate usage of Bicep features together with AzOps.

Sep 30 '24 14:09 Jefajers