Variable Substitution in bicepparams

[jachin84]

I have spotted a pattern emerging in one of our Bicep repos where the parameter files for different environments are very similar. Consider the comparison below.

As you can see these files are mostly the same. There is an argument you could move some of this configuration into the main Bicep file but I'm not keen on this approach. What I'd like is a way to do variable substitution in the params file. Something like how Octopus Deploy does variable substitution, https://octopus.com/docs/projects/variables/variable-substitutions. This is done using https://github.com/OctopusDeploy/Octostache.

This would allow something like this:

param resourceGroupName = '#{resourceGroupName}'

The variable could be supplied via another bicepparam file or even pulled in from environment variables. I suspect there may be a solution to this already but I'm yet to find it in my searching/experimentation. Thanks in advance!

[johnlokerse]

Hey @jachin84, there is a way to do this in Azure Bicep too. Probably via multiple ways, but I like to use environment variables to set the DTAP environment. In the Bicepparam file you can use the readEnvironmentVariable function to achieve what you want: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-functions-parameters-file#readenvironmentvariable

(plug) I have written a blog on how I use Azure Pipelines to supply environment variables to the Bicepparam file: https://johnlokerse.dev/2023/10/02/work-with-environment-variables-in-azure-bicep/

[jachin84]

Thanks @johnlokerse, not a bad idea but still not quite what I had in mind. I could make this work but there would be a lot of env vars.

I thought Extendable Param Files might solve this for me but note quite.

I have a deployment that changes reasonably regularly. For this reason, it's structured in such a way that those change can be driven from the params file. The downside is that the param file gets large. There is then a very large param file per-environment with minimal differences.

Think something like a main param file prod.bicepparam and then a secondary param file such as demo.bicepparam, regiona.bicepparam, regionb.bicepparam. You get the idea.

The contents of a secondary param file, regionb.bicepparam for example:

param identityAName string = 'foo'
param resourceAName string = 'bar'

I know this isn't fundamentally different to the readEnvironmentVariable approach you mention however the key difference is keeping the configuration in code rather than in env vars.