Module Naming

Naming

We are following the default naming conventions enforced on the Terraform Registry for terraform modules.

Each Brick and Wrapper needs its own repository in the LederWorks Organization based on the following rules for Bricks:

language-provider-easy-brick-category-purpose

and for Wrappers:

language-provider-easy-wrapper-purpose

• Every word is delimited by hyphens.
• The first word of every module is the language the majority of the code is written, eg. terraform, bicep, ansible, golang etc.
• The second word is either a terraform provider or a class used by the cloud API.
• The third word is easy, you can replace that with your organization name for example.
• The fourth word is either the brick or wrapper, depends on the type of the module.
• The fifth word for Bricks is the category under the provider structure.
• The sixth (or fifth for Wreappers) and consequent words are the purpose, which needs to be unique within the organization. We are suffixing the input parameters and variables with this using snake_case, eg. for: terraform-azurerm-easy-container-aks-cluster all variables will be prefixed with aks_cluster

Terraform Bricks

terraform-azurerm-easy-brick-compute-linux-vm

• The second word is the provider the majority of the code is written in, eg. azurerm, azuread, kubernetes, helm etc.
• The third word is easy. If you implementing these standards somewhere else, this most possible will be yout company, organization etc. name.
• The fourth word is either the brick or wrapper, depends on the type of the module.
• The fifth word is the category the resource under on the Terraform Registry documentation, eg. compute, container, storage etc. If that is more than 2 word eg. Logic App, the do not use any delimiters, write in a single word, eg. logicapp.
• Any subsequent words should clearly state, what that module is used for eg., if it’s deploying a Linux VM, then it should be linux-vm.

Terraform Wrappers

terraform-azurerm-easy-wrapper-aks-cluster

• The second word is the provider the majority of the code is written in, eg. azurerm, azuread, kubernetes, helm etc.
• The third word is easy. If you implementing these standards somewhere else, this most possible will be yout company, organization etc. name.
• The fourth word is wrapper.
• Any subsequent words should clearly state, what that module is used for and delimited by _. If it is deploying an AKS Cluster, then it should be aks-cluster.

Bicep Bricks

bicep-managedidentity-easy-user-managed-identity

• The second word is the second part of the ARM API Documentations resource, eg. for Microsoft.Network/ it is going to be network.
• The third word is easy. If you implementing these standards somewhere else, this most possible will be yout company, organization etc. name.
• Any subsequent words should clearly state, what that module is used for. If it is deploying a DataBricks workspace it is going to be databricks-workspace.

Bicep Wrappers

bicep-easy-wrapper-databricks-isolated-vnet

• The second word is easy. If you implementing these standards somewhere else, this most possible will be yout company, organization etc. name.
• The third word is wrapper.
• Any subsequent words should clearly state, what that module is used for. If it is deploying a DataBricks deployment in an island vnet, then it is going to be databricks-isolated-vnet.

GoLang Modules

golang-easy-terratests

As Go Modules in general importing several packages, I do not think that we need to include this information in the name of the respective repository.

• The second word is easy. If you implementing these standards somewhere else, this most possible will be yout company, organization etc. name.
• Any subsequent words should clearly state, what that module is used for. If it is used for terratests, then it should be terratests.