Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Single Template with Multiple Parameter Files #831

Closed
Xitric opened this issue Nov 29, 2023 · 1 comment · Fixed by #836
Closed

Support Single Template with Multiple Parameter Files #831

Xitric opened this issue Nov 29, 2023 · 1 comment · Fixed by #836
Assignees
Labels
enhancement New feature or request
Projects
Milestone

Comments

@Xitric
Copy link
Contributor

Xitric commented Nov 29, 2023

Describe the solution you'd like

Our team manages a large set of Bicep deployments in our Azure tenant. The way that our applications are designed requires a fair amount of resources to be deployed for each customer on our solution. We have a few fairly large customers, so the design scales appropriately, but it is still becoming an issue to keep track of all these customer-specific deployments via imperative pipelines, especially during upgrades.

For this reason, we are looking into managing all application and customer deployments via AzOps. Every customer is based on the same exact Bicep module stored in our container registry, but parameterization is slightly different. In order to reference this external Bicep module in AzOps, we need to wrap it in a template and proxy all the parameters through to the module. We feel that duplicating the Bicep "wrapper" template for every customer will not scale well, since they will be exact copies of one another, and the set of parameters we proxy through the template in the AzOps repository is not exactly short:

subscription/
├── customer-a.bicep
├── customer-a.parameters.json
├── customer-b.bicep
├── customer-b.parameters.json
├── customer-c.bicep
└── customer-c.parameters.json

Our goal is to have a declarative set of customer-specific parameter files and a single Bicep template, as such:

subscription/
├── customer.a.parameters.json
├── customer.b.parameters.json
├── customer.c.parameters.json
└── customer.bicep

We don't feel strongly about the naming convention for correlating parameter files to template files, so either of these could work:

  • customer.bicep <-> customer.<id>.parameters.json
  • customer.bicep <-> customer.parameters.<id>.json

Adding a parameter file

Whenever a parameter file is added, we expect a deployment to take place of the corresponding Bicep file for that new parameter file only. Deployments based on other parameter files must be unaffected.

Modifying parameter files

Whenever a set of parameter files are modified, we expect a deployment to take place of the corresponding Bicep file for each of the changed parameter files only. Deployments based on unmodified parameter files must be unaffected.

Modifying the template

Whenever the Bicep or ARM template is modified, we expect a deployment to take place for every corresponding parameter file.

@daltondhcp daltondhcp added triage enhancement New feature or request labels Dec 4, 2023
@Jefajers Jefajers changed the title Support multiple parameter files per ARM or Bicep template Support Single Template with Multiple Parameter Files Dec 4, 2023
@Jefajers
Copy link
Member

Jefajers commented Dec 4, 2023

Split the additional different capabilities into different features: #832 and #833

@Jefajers Jefajers removed the triage label Dec 5, 2023
@Jefajers Jefajers added this to the v2.4.0 milestone Dec 7, 2023
@Jefajers Jefajers added this to In progress in AzOps Dec 7, 2023
@Jefajers Jefajers moved this from In progress to Pending release in AzOps Dec 19, 2023
@Jefajers Jefajers moved this from Pending release to Done in AzOps Dec 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
AzOps
Done
Development

Successfully merging a pull request may close this issue.

3 participants