Environments are useful to provision different resources with different settings e.g., dev vs. prod, Key Vault vs. Managed HSM, etc. Customizing these with environment variables (env vars) can be difficult, though. While most *nix shells e.g., bash let you pass them on the command line e.g., FOO=1 BAR="true" azd provision, shells typical of Windows e.g., cmd and pwsh, do not. Setting env vars can be dangerous, too. In my example above, what happens if we forget to re-set an env var for a dev connection string and it's left as the prod connection string? What if we provision an expensive Managed HSM resource (uptime cost) when we thought we were provisioning a Key Vault (per-call cost)?
After some internal discussion about adding a --parameters parameter vs. other means, it seems we've settled on making persistent parameters via an environment's config.json file. This is already used for retaining selections when prompted, but doesn't seem to work if you just edit it by hand (likely due to a bifurcation of global vs. provider-based parameters).
To make this a first class feature of environments, instead we could have a command group like azd env (-e name) config with typical set, get-values, etc., commands to get, set, clear, etc., parameters. These could be restricted to only those in main.parameters.json, though I think allowing them for any parameters in the main.bicep (or main.json) template would be useful. Maintaining a separate main.parameters.json seems better if it's only to default to env var replacements.
These parameters would persist past an azd down. Customers should be able to deprovision resources to reduce costs during the dev inner loop, for example.
Environments are useful to provision different resources with different settings e.g., dev vs. prod, Key Vault vs. Managed HSM, etc. Customizing these with environment variables (env vars) can be difficult, though. While most *nix shells e.g., bash let you pass them on the command line e.g.,
FOO=1 BAR="true" azd provision, shells typical of Windows e.g., cmd and pwsh, do not. Setting env vars can be dangerous, too. In my example above, what happens if we forget to re-set an env var for a dev connection string and it's left as the prod connection string? What if we provision an expensive Managed HSM resource (uptime cost) when we thought we were provisioning a Key Vault (per-call cost)?After some internal discussion about adding a
--parametersparameter vs. other means, it seems we've settled on making persistent parameters via an environment's config.json file. This is already used for retaining selections when prompted, but doesn't seem to work if you just edit it by hand (likely due to a bifurcation of global vs. provider-based parameters).To make this a first class feature of environments, instead we could have a command group like
azd env (-e name) configwith typicalset,get-values, etc., commands to get, set, clear, etc., parameters. These could be restricted to only those in main.parameters.json, though I think allowing them for any parameters in the main.bicep (or main.json) template would be useful. Maintaining a separate main.parameters.json seems better if it's only to default to env var replacements.These parameters would persist past an
azd down. Customers should be able to deprovision resources to reduce costs during the dev inner loop, for example.