ResourceModules VS Nerdbank.GitVersioning

That is a great question, and not the least because it's the one I've been struggling with for the past few years. As for Azure and Bicep, we tried out a few things until we found out about the Common Azure Resource Modules Library (https://github.com/Azure/ResourceModules) and started experimenting on how to leverage that. Wheter you find such modules useful or not, I would suggest taking a look at the module design principles they have (https://github.com/Azure/ResourceModules/wiki/The%20context%20-%20CARML%20library), which I've found to be great.

In general resource group is lifecycle and deployment boundary. So your Bicep or ARM templates should deploy resource groups with all resources included. To make it easier you can use resource modules from https://github.com/Azure/ResourceModules.

For modularized Bicep, I'd suggest you to take a look at Common Azure Resource Modules Library - probably not much of an use right now if you have implemented everything, but could be of use if you feel like refactoring something. I wouldn't suggest it as an example on how to do custom bicep implementation, but one can certainly take some inspiration from there, if not directly using the modules.

What I found is that using the Resource Modules (https://github.com/Azure/ResourceModules) repo is the best approach. It simplifies the authoring quite a lot in my opinion. And every module on the repo is bicep. But since the modules are created by Microsoft/the community, not every resource or service has a ready module. I have been using it for the last 6-8 months, and find it covers 90% of my scenarios. And each module is quite well documented, but in some cases you have to study the module to figure out the required inputs.

We don't have a team in place to update and maintain modules so that's where my thought about CARML comes into the picture. Unsure how this is maintained though and how to update the modules, and i think it makes it more complex and hard to understand for people unfamiliar with IaC.

i have been using Nerdbank GitVersioing https://github.com/dotnet/Nerdbank.GitVersioning

The https://github.com/Azure/ResourceModules repo (which I recommend strongly, if you are just starting with template specs/bicep modules) seems to be at least referencing https://github.com/dotnet/Nerdbank.GitVersioning though when I peeked at their pipelines I'm not sure if they are actually utilizing it for version numbers. For me it was a bit too complex approach, but might suit you.

So, is there a complexity with delivering a NuGet package? Yes. NuGet package versioning can be a big undertaking when it comes to manual deployments, much less CD; as there is a requirement of NuGet packages being immutable. Does this mean that for every check in, on every potential branch that will be pushed to NuGet, you need to update some text file or code to indicate the next built version? That was my initial thinking, but thankfully that is not the case with the help of Nerdbank.GitVersioning.

I would suggest you compare with the readme on https://github.com/dotnet/Nerdbank.GitVersioning (FD: this is what I use for versioning my projects, so I'm already very familiar with it), which has most of the details up front (i.e. I don't have to go browsing through multiple wiki pages). It clearly calls out: - What does the package accomplish? (it adds semver information based on git history) - What is it compatible with? ("[dotnet] assemblies, VSIX, NuGet, NPM, and more") - What sets it apart? (#1: every commit generates a unique version, and builds reproducibility is prioritized. #2-4: everything is automatic.) - Further down it talks about how it calculates versions, and how to calculate between versions and git commits (i.e. how does the automatic part work)

GitVersioning. Auto-increments based on commit. Integrates into your build and automatically adds AssemblyInfo. https://github.com/dotnet/Nerdbank.GitVersioning

How to adopt a versioning strategy using tools like Nerdbank GitVersion