Deployment name best practices in bicep

[marcosikkens]

When dolng bicep deployments I often run into the problem where my deployment name exceeds 64 characters. What however is not very clear is how good deployment names are made.

Suppose i have the following example deployment:

1.Create Resourcegroup 1.1 Create keyvault 1.2 create RBAC for other resource on keyvault

Usually my deployment names start with something unique so i use -timestamp for the main deployment on the RG, The 'sub' deployment have an own unique name and get a suffix so you can can see what is what.

1 testdeploy-20251114 1.1 testdeploy-20251114-rg 1.2 testdeploy-20251114-keyvault 1.3 testdeploy-20251114-keyvault-rbac

(the numbering is just to indicate what belongs together and that there is a hierachical aspect to a deployment,

This makes it that on each level of the deployment you know what happens for what deployment. Also this example doesnt deploy stuff to different resourcegroups but you get the general idea.

Describe the solution you'd like A clear and concise document which states how to handle deployment names (or a fix for the 64 character deployment name limit). Giving best practices on how to make those names unique BUT still readable and tracable in the azure portal.

OR

Fix the 64 characted limit! Deployment name should be a value that mean something. We are not doing mainframe programming in 1980.

[anthony-c-martin]

One thing to mention if you haven't seen it is the new "optional module names" feature: https://johnlokerse.dev/2025/04/01/azure-bicep-optional-module-names-explained/

Or are you specifically looking to represent the hierarchy via the name?

[marcosikkens]

HI thanks for the quick response, well the hierarchy would really helpfull. The reason is that when you deploy on multiple resourcegroups it helpful to see where a (child) deployment belongs to. Automatic deployment would help with the 64 character limit however because it is more difficult to exceed 64 characters. but there is still no way to move up the tree and see what triggered a deployment action

Deployments are still really hard to trace in the azure portal then.. I think the main issue is that there is no complete list of deployments in the azure portal. When you deploy on a RG, you find it onder deployments there, when you deploy on subscription you find it there.

But no location to see a hierachical view of all deployment done on a 'global' level.