Allow `main.parameters.json` to be read from `.azure/{environmentName}/`

[JayDoubleu]

There seems to be a requirement that the parameters file such as main.parameters.json, must be located in the same directory as main.bicep.

For enhancing flexibility and organization, it would be beneficial to allow the main.parameters.json file to be read from environment directory, .azure/{environmentName}/.

In the scenario where the main.parameters.json file is not found in the .azure/{environmentName}/ directory, the system should fall back to the default behaviour of looking in the same directory as main.bicep.

This modification would provide more flexibility in structuring projects and managing environments.

[rajeshkamal5050]

Seems to be a fair ask in-terms of keeping all things related to azd's environment configuration + its runtime(inputs/outputs) @savannahostrowski @ellismg thoughts?

[ellismg]

I'm not opposed to this in theory - but I am a little nervous that it is going to lead folks to check in the .azure folder, since this main.parameters.json file is now "interesting", and I'm a little worried about walking down this path.

We do allow environment variable substitution on this file, so you can already make it specific to environments, but it is a little less direct than just supporting separate files.

I think if we do this, we may want to consider a design where values in the environment specific folder override the global one instead of just selecting one or the other.

But we would have to figure out what this would mean when trying to remove a setting that was set in a global file.

@JayDoubleu - In your case, if you had this, how would you manage these files? Would you end up checking them in?

[JayDoubleu]

@ellismg Yes, it's a common pattern to define multiple environments and then provision each one by simply providing --environment xxx. While I understand that the main purpose of this project is to enable developers to swiftly provision solutions ready for demonstration, I believe it's filling a significant gap in the tooling used by platform engineering teams.

I envision this tool being primarily used by platform engineering teams, pre-tested and ready for developers to incorporate their code into the src folder.

Personally, I would also recommend changing the .azure folder from being hidden to being a first-class configuration folder. This is often the case for bicep and terraform code we develop. We would simply instruct the end user of this code to "copy" .azure/environment_template into their desired environment name, change default values, and then run azd up --environment.

As it stands right now, we have no tool do deploy the code AND package apps with zipdeploy as an option. If we would only add --plan or --whatIf to this workflow It's going to gain popularity amongst platform engineering teams very quickly.

But that's just my opinion

PS. I would also appreciate if someone could look into the "discussions" tab on this repo as I'm not sure the notifications are set the same way as issues.

[jongio]

Jay - Have you seen azd env refresh? That would get you env portability. Have a look and LMK if that helps.

I can jump on a call if you'd like to discuss.

[nahlian]

Bicep now supports user-defined data types. With this, I can expose options in the .bicepparam. Each parameter gets a nice drop down list of options that the developer can select.

However, without being able to point to a specific .bicepparam file, working with multiple environments is cumbersome.

I understand not wanting to muck around in the .azure directory. What if the parameters file name matches the environment name? IE: dev.bicepparam

Maybe I missing something obvious but in the FAQ, there main.parameters.json per environment. How does this help with multiple environments today, substitution syntax? That means the flow is create parameters file, update with substitution syntax, and then go add the values in the .env file?

https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/faq#what-is-an-environment-name

[jongio]

How does this help with multiple environments today, substitution syntax? That means the flow is create parameters file, update with substitution syntax, and then go add the values in the .env file?

When you call "read from env var" in the biccepparam file it will use env vars that are in the current azd env, as azd loads the env vars from the current env before executing any command.

i.e.

1. Run azd deploy
2. azd will find the current env and load that .env into process
3. Bicepparam with "load from env var" method use will automatically find that env var that is loaded into process and use it.

Make sense?

[nahlian]

I was trying to avoid using the readEnvironmentVariable() as I like the tab completion from the user defined types. Appears my desired flow is an edge case. Thank you for the reply and your time.