Repo structure after pull - to be followed with Bicep deployments?

[BenjaminEngeset]

Hi there project maintainers and contributors.

Repo structure after pull is great.

But when working with Bicep or JSON for new/or change in existing configuration deployments, should deployments just be under the same structure?

Should i just create main.bicep or storage.bicep or containerregistry.bicep with main/storage/containerregistry.parameters.json directly under the resource group subfolder avd-weu-p-vnet-rg?

I have tested that and it works well. It is also pulling the created resource/s with their .json after with the unique identifier.

But that is duplication, so I am doubting using Core.SkipResource: false and Core.SkipChildResource: false. It seems like there is some sort of inbuilt prioritizing, so for next push it will use the unique generated .json and overlook main.bicep.

Is this how it is supposed to be managed?

I don't fully understand the documentation:

Do the project have some examples around this certain topic?

It seems to be very intelligent. First time it deploys the main.bicep. When running manually push again it will run the microsoft.containerregistry_registries-acrufyi3twmk7oqo.json which was based of first deployment with main.bicep and just overlook the main.bicep.

Truly grateful for answers.

/b

[BenjaminEngeset]

Can be closed.

After watching the great video from Simon Wåhlin I got all the answers.

[BenjaminEngeset]

Tutorials could be great. I am keen to know more about the canary and prod setup. Is that deprecated and not maintained anymore? I am about to implement this on 1000+ subscriptions, so would really like to know if I am doing rather a mistake going for the canary and prod setup and if there are any major advantages at all besides the obvious splitted security principals. I do believe that the "normal" setup can serve as canary and prod as well.

[XristophD]

sorry to reply to an old comment, but could you point me to the great video from Simon Wåhlin that got you all the answers?
I am not able to find it, looking for similar explanations.

[petropmi]

Me too, could you please share a link with the video? Thx!

[BenjaminEngeset]

@XristophD @petropmi

https://www.youtube.com/watch?v=EIMdO521EhQ

I don't remember the timestamp, but Simon explains the structure here and what will happend.

[petropmi]

Thank you!

[ri-we]

@SimonWahlin I'm struggling with the way of working even after watching the video. You dump e.g. a storage.bicep file in a folder. After a full cycle it becomes obsolete imo, since the pull generates this unique arm template for that same storage.bicep. To keep the repo clean, should I remove the storage.bicep?

[BenjaminEngeset]

@ri-we

Just from my personal experience, the generated ARM template can be considered just as backup. You will both have .bicep and .arm being the same end-product in the folder when you are working with Bicep.

You can configure AzOps to behave that it overlooks resource declarations, then it will not pull those resources in.

When you configure AzOps to overlook resource declarations (resources, child and extension resources) it will give you something that makes more sense.

What you can do is to run a seperate repo that is pulling in everything and run that as your "backup". Then in the other repo, AzOps is configured to overlook (resources, child and extension resources).

I am sure that AzOps will support pulling in .bicep later on, but currently there is no good way of doing it.