Description
openedon Oct 3, 2024
Background
azd users currently define a mapping between environment variables (AZURE_ENV_NAME
) and Bicep parameters (envName
) inside main.parameters.json
and main.bicepparam
. While this works, from a UX perspective, it introduces another point of configuration with users. The environment substitution syntax, while powerful and used in many advanced cases, is also a potential source of misconfiguration due to lacking of upfront tooling validation.
Proposal
Define an automatic naming translation rule between environment variables and provisioning parameters. When variables are not mapped explicitly, azd
will automatically allow for an environment variable override for parameters.
Some useful background to consider:
- For Terraform, this already exists as
TF_VAR_<case sensitive variable name>
, described in the Terraform docs. - For Bicep, this convention does not yet exist. However, we are currently using scaffold.EnvFormat for some Aspire-related work.
Some properties of this proposal:
- This proposal would not change the current explicit mapping behavior.
- This proposal would contribute towards a design where
pipeline config
would set individual key-values rather than a JSON object, such asAZD_INITIAL_ENVIRONMENT_CONFIG
. This would help with troubleshooting and debugging for DevOps scenarios.
Risks
For advanced DevOps users that are largely familiar with the Azure Bicep ecosystem, there may be slight hesitation towards adopting environment variables as input parameters (even if they are just overrides). An observation that may reduce assessment of this risk is that we have seen through wide-usage of environment variables over parameter files based on current azd usage in the template ecosystem.