-
Notifications
You must be signed in to change notification settings - Fork 512
Contributing
Looking to contribute to this project, whether that be Bicep code, examples, documentation or GitHub automation, you are in the right place. Please review the rest of this wiki page for important information to help you to start contributing to the project effectively.
Before you start contributing to the ALZ Bicep code, it is highly recommended that you complete the following Microsoft Learn paths, modules & courses:
- Deploy and manage resources in Azure by using Bicep
- Structure your Bicep code for collaboration
- Manage changes to your Bicep code by using Git
To contribute to this project the following tooling is required:
The following tooling/extensions are recommended to assist you developing for the project:
- CodeTour extension for Visual Studio Code
- ARM Tools extension for Visual Studio Code
- ARM Template Viewer extension for Visual Studio Code
- Bracket Pair Colorizer 2 extension for Visual Studio Code
The below guidelines should be adhered to whilst contributing to this projects Bicep code.
Throughout the development of Bicep code you should follow the Bicep Best Practices.
It is suggested to keep this page open whilst developing for easy reference
- Camel Casing must be used for all elements:
- Symbolic names for:
- Parameters
- Variables
- Resource
- Modules
- Outputs
- Symbolic names for:
- Use parameter decorators to ensure integrity of user inputs are complete and therefore enable successful deployment
- Only use the
@secure()
parameter decorator for inputs. Never for outputs as this is not stored securely and will be stored/shown as plain-text!
- Only use the
- Comments should be provided where additional information/description of what is happening is required, except when a decorator like
@description('Example description')
is providing adequate coverage- Single-line
// <comment here>
and multi-line/* <comment here> */
comments are both welcomed - Provide contextual public Microsoft documentation recommendation references/URLs in comments to help user understanding of code implementation
- Single-line
- All expressions, used in conditionals and loops, should be stored in a variable to simplify code readability
- Specify default values for all parameters where possible - this improves deployment success
- The default value should be called out in the description of the parameter for ease of visibility
- Default values should also be documented in the appropriate location
- Tab indents should be set to
2
for all Bicep files - Double line-breaks should exist between each element type section
- Each bicep file must contain the below multi-line comment at the very top of the file, with its details filled out:
/*
SUMMARY: A short summary of what the Bicep file does/deploys.
DESCRIPTION: A slightly longer description of what the Bicep file does/deploys and any other important information that should be known upfront.
AUTHOR/S: GitHub Usernames
VERSION: 1.0.0
*/
<REST OF BICEP FILE BELOW...>
targetScope = ...
etc...
Element Type | Naming Prefix | Example |
---|---|---|
Parameters | par |
parLocation , parManagementGroupsNamePrefix
|
Variables | var |
varConditionExpression , varIntermediateRootManagementGroupName
|
Resources | res |
resIntermediateRootManagementGroup , resResourceGroupLogAnalytics
|
Modules | mod |
modManagementGroups , modLogAnalytics
|
Outputs | out |
outIntermediateRootManagementGroupID , outLogAnalyticsWorkspaceID
|
For all Bicep files created as part of this project they will follow the structure pattern of being grouped by element type, this is shown in the image below:
Parameters, Variables, Resources, Modules & Outputs are all types of elements.
Below is an example of Bicep file complying with the structure and styling guidelines specified above:
/*
SUMMARY: An example deployment of a resource group.
DESCRIPTION: Deploy a resource group to UK south taking a naming prefix as it's only parameter.
AUTHOR/S: jtracey93
VERSION: 1.0.0
*/
// SCOPE
targetScope = 'subscription' //Deploying at Subscription scope to allow resource groups to be created and resources in one deployment
// PARAMETERS
@description('Example description for parameter. - DEFAULT VALUE: "TEST"')
param parExampleResourceGroupNamePrefix string = 'TEST'
// VARIABLES
var varExampleResourceGroupName = 'rsg-${parExampleResourceGroupNamePrefix}' // Create name for the example resource group
// RESOURCE DEPLOYMENTS
resource resExampleResourceGroup 'Microsoft.Resources/resourceGroups@2021-04-01' = {
name: varExampleResourceGroupName
location: 'uksouth' // Hardcoded as an example of commenting inside a resource
}
/*
No modules being deployed in this example
*/
// OUTPUTS
output outResourceGroupExampleID string = resExampleResourceGroup.id
To author Bicep modules that are in-line with the requirements for this project, the following must be true:
- Follows the Bicep Formatting Guidelines as detailed above
- A new folder per module in the following directory:
infra-as-code/bicep/modules/...
- Folder Name will be created with camel case:
infra-as-code/bicep/modules/moduleName
- Folder Name will be created with camel case:
- Each new module folder must contain:
-
A
media
folder that will contain images used in theREADME.md
-
A
README.md
for each module in the root of its own folder, as above, detailing the module, what it deploys, parameters and any other useful information for consumers.- The
README.md
must also contain a Bicep visualizer image of the complete module
- The
-
A
bicepconfig.json
for each module in the root of its own folder.-
The
bicepconfig.json
file should contain the following:{ "analyzers": { "core": { "enabled": true, "verbose": true, "rules": { "no-hardcoded-env-urls": { "level": "error" }, "no-unused-params": { "level": "error" }, "no-unused-vars": { "level": "error" }, "prefer-interpolation": { "level": "error" }, "secure-parameter-default": { "level": "error" }, "simplify-interpolation": { "level": "error" }, "adminusername-should-not-be-literal": { "level": "error" } } } } }
-
The Bicep module file & parameters file, complete with default values.
-
If you discover any documentation bugs or would like to request new content, please raise them as an issue on the repo.
Contributions to this wiki are done through the main repo under docs/wiki.
- Wiki Home
- Deployment Flow
- Consumer Guide
- How Does ALZ-Bicep Implement Azure Policies?
- How Does ALZ-Bicep Implement resilient deployments across availability zones?
- Contributing
- Telemetry Tracking Using Customer Usage Attribution (PID)
- Azure Container Registry Deployment - Private Bicep Registry
- Sample Pipelines
- Code tours