Introduction to Azure Bicep v 0.4.x

Azure Bicep is the new domain-specific language to deploy your resources in Azure using a declarative syntax. The main difference with ARM templates, Bicep uses a more concise syntax and helps you to scale your deployment without having to pull out your hairs.
Since version 0.3, in March 2021, Bicep is supported Microsoft Azure support plans. It means that you can create a support ticket for any problem related to Bicep in Azure and you will get a response.

Bicep Doc in Microsoft Doc and Microsoft Learn

One of the big changes, Bicep is no longer only present on GitHub. Bicep is now present on Microsoft Doc.
You have, also, access to several pieces of training on Microsoft Learn

Installation

You can install Bicep by using Howbrew on MacOs, by Windows Installer or Chocolatey on Windows, or by downloading the binary files on Linux.
But you can also install (and upgrade) Bicep by using Azure CLI.
You need to make sure that you run at least version 2.20.0, and you can use the command

az bicep install

If you want to upgrade your current installation, you can use

az bicep upgrade

But if you use Azure CLI to install bicep, it will not update PATH, so you will need to do it manually after.

A PowerShell version of this installer will be available soon.

AZ CLI & Azure PowerShell integration

Until Bicep version 0.3, you will have to compile your Bicep files and use Azure PowerShell or Azure CLI to deploy the JSON files you get from the Bicep Build command. But since you can directly deploy your Bicep file using your favorite toolings.

For Azure PowerShell, you need to make sure to use, at least, the Az PowerShell module in version 5.6.0. For Azure CLI you will need to use version 2.20.0.

You will be able to use new-AzXXXDeployment Cmdlet (resourceGroup, ManagementGroup, Subscription, or Tenant) with the path to your Bicep file as the value for the -TemplateFile parameter.
If you need to pass parameters, you have two options; using the inline form if you only have a few or using a parameter file if you have more. In this last case, the Bicep parameter file is just a standard JSON Template parameter file.

TemplateSpec, the other new technology for Azure deployment is not yet available with Bicep.

Bicep Visualiser

Another nice feature, coming from the 0.3.539 version is the integrated visualiser in VSCode.
After you have updated both your local Bicep installation and the Bicep extension in VSCode you can now generate a graph in VSCode based on your Bicep code.
Simply open a Bicep file in the editor and you should have a similar at the upper right of the editor

Click on the

And you should get the graph of your resources and dependencies.

Bicep Linter

With version 0.4.x, you have access to a linter.
If you don’t know what a linter is? It’s a tool used that can analyse your source code to highlight coding and stylistic errors before going into production. PSScriptAnalyser is an example of a linter for PowerShell.
The linter integrated with Bicep is based on some of the rules present in ARM-TTK.

To enable the Bicep linter, you need to create a bicepconfig.json at the same directory as your file.

The minimal configuration is

{
    "analyzers": {
      "core": {
        "verbose": false,
        "enabled": true,
        "rules": {}
      }
    }
}

Here, the linter is enabled and the default. The verbose property, if enabled, will tell you which bicepconfig.json file is used.
The rules property lets you enable the linter rules you need. You can find these rules here.

• no-hardcoded-env-urls
• no-unused-params
• no-unused-vars
• prefer-interpolation
• secure-parameter-default
• simplify-interpolation

Each rule has at least one property, level. This property commands the behavior of Bicep if the case if found in the Bicep file.
You can use several values for level:

• Error, if the situation is meet, for example, if you enable the no-unused-params, for example, and you left an unused param in your file, the build command will fail. It’s useful in a CI/CD scenario.

• Warning, in this situation, you will have a warning message, but the build process will continue, and your bicep file will be translated into its JSON counterpart

• Info, in this situation you will get a verbose message

• Off, the rule is disabled

As you see, you can build a CI/CD using the new linter. To perform a check with the linter, simple run the Bicep Build command.

Let’s start with a simple bicep file that creates a storage account

param storageAccountName string
param containerName string = 'logs'
param location string = resourceGroup().location
param myUseLessParal string
var mylocation = 'francecentral'

resource sa 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
    tier: 'Standard'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

This Bicep file has one parameter and one variable not used anywhere in the configuration.
Now we want to stop raise an error if a parameter or a variable created in the Bicep file is not used in the build should fail.

You need to create this bicepconfi.json file at the same level.

{
    "analyzers": {
      "core": {
        "verbose": true,
        "enabled": true,
        "rules": {
          "no-unused-params": {
              "level": "Error"
          },
          "no-unused-vars": {
            "level": "Error"
        }
        }   
      }
    }
  }

When you run:

bicep build ./storage.bicep

You should get

This new version of Bicep has many improvements, and you can no use it easily in your CI/CD scenarios.