bicep registry usage - test and prod?

[housten]

We are setting up bicep modules in a bicep registry. Our first inclination is to have a test and a production registry, however, I don't quite see how to do that without having to have duplicate module entries corresponding to each registry type and some condition like the psuedo bicep below

module destinationQueues 'br:bicepregistrytest.azurecr.io/queue:1.0' = if env == 'test' {
...
}
module destinationQueues 'br:bicepregistryprod.azurecr.io/queue:1.0' = if env == 'prod' {
...
}

I first tried constructing the resource type using a variable which seemed natural but that doesn't work... Something like this, but I don't think this is exactly what I tried so maybe this variation works...

param env string = 'test'
param versionTag string = '1.0'
var moduleType = 'br:bicepregistry${env}.azurecr.io/queue:${versionTag}'
module destinationQueues '${moduleType}' = {

I was looking at the bicep.config aliasing but I don't quite see how that would help. It looks like the bicep config file has one default name bicepconfig.json so one can't have separate alias files for prod and test, and I would still have to hard code a specific alias rather than have a dynamic one.

How is it recommended that one handle the difference between modules under development and production ready modules? Just by versioning? Or have I missed something?

thanks!

[brwilkinson]

Hi @housten

Not sure on an answer here, however wanted to add some information to the conversation.

• https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-config?source=recommendations

You can add bicepconfig.json files in multiple directories. The configuration file closest to the Bicep file in the directory hierarchy is used.

It's hard to imagine having a /dev/main.bicep and a /prod/main.bicep to have 2 separate bicepconfig.json files.

• In that case /$enviro/main.bicep could be an option.

Perhaps if they were just wrappers that pass thru params to the actual main.bicep Etc.

Perhaps there is a way to make it work by adding the file to gitignore and have the file manually managed or downloaded in separate branches. Then use the same alias, that points to the different ACR.

It might be helpful if you can share more on your branch strategy or how you plan to deploy between dev and prod. E.g. Different ADO pipelines or if you also do local deployments to dev etc.

It's easier to make things work when dev vs prod are the same ACR however you have separate branches, then dev has newer tag/version of the Module, that eventually gets merged to main branch.

Having standalone tests for your modules and an automated CI to execute these in your pipeline becomes a whole other process or repo than the set of orchestration Modules that get executed to actually deploy and consume the modules from ACR.

Did you spend time reviewing?

• https://github.com/Azure/bicep-registry-modules
• https://github.com/Azure/ResourceModules

[housten]

Thanks @brwilkinson, I will look at those links, I will answer your questions now, in case that triggers any other thoughts. :)

I am expecting that deployment will always happen from the ADO pipeline, and that there will be feature and main branches, with only main being allowed to go to production.

I prefer to, as much as possible, use the same files and pipelines for all environments and just control resources by concatenating in the environment name. In my experience, every 'duplicated' file or module introduces an opportunity for mistakes. I have a level of comfort in knowing that a file/pipeline has worked in previous environments before it runs in production.

[brwilkinson]

@housten

Here is an open issue for providing an alternate bicepconfig file for different environments

• Add an optional parameter to bicep build to specify the config file to use #5013

I believe that would be a good way to managed this overall.

• please follow or comment over there to add your support for the feature.

[housten]

@brwilkinson Those were really interesting repositories for getting really in depth with Bicep, thanks!

I didn't see anything that really helped regarding my use case. I'd love to see something that allows putting a variable in the type field, but I guess that would make the type checking controls difficult.

I will follow that config file issue; that could lead somewhere fruitful, thanks!

[brwilkinson]

The reason I mentioned those repos is because you might want to consider having a module library project, similar to those, where you build your modules and publish them into ACR.

Then you would have separate project/s with your wrapper bicep, that consumes the modules. This may impact your overall design.