Bicep templates can easily be flexible and reusable meaning you don’t have to always write new code for every deployment you want to do. One good example of this is using the same Bicep template to deploy to your production and non-production environments. You would typically not want to deploy resources using the same replication or pricing tier in your non-production environment as in your production environment so you can save money in your non-production environment. For example, if you were deploying a storage account in the production environment, you might use Standard_GRS SKU for high resiliency. And if you were deploying an App Service Plan you might deploy at the P2v3 SKU for high performance. But when you deploy to the non-production environment you might deploy the storage account with Standard_LRS SKU and the app service plan with the free F1 SKU.
We can do this in Bicep by using a parameter which uses a parameter decorator, in this instance called allowed, which gives us the ability to say these are the valid values allowed in this parameter. In this example, we’ve stated that the environmentType can only be nonprod or pod. So when someone goes to deploy this Bicep template they will only be allowed to provide a value for this parameter of nonprod or prod.
We can then expand on this parameter and use variables to put some IF statements in place which use our environmentType parameter. This puts some rules in place to determine what SKU’s we’re going to use in each environment.
The ? Symbol below acts like an IF statement.
This says, if the environmentType parameter is prod
Then, we want the storage account SKU name to be Standard_GRS.
Otherwise, shown with the : symbol.
We want the storage account SKU name to be Standard_LRS.
You can use the same logic to specify the appServicePlanSkuName by specifying if the environmentType is prod then use the app service plan SKU name P2v3, otherwise use F1.
