I’ve been working recently with Bicep files to create Azure environments as part of CI/CD pipelines. Sometimes figuring out how to structure something in a Bicep file can be a struggle, and the errors can be challenging to interpret. Here are a few tips to improve your workflow when working with Bicep.

1. Don’t Start From Scratch

Blank canvas syndrome is a genuine problem. It isn’t easy to know where to start. Fortunately, starting from nothing isn’t your only option. You can create your environment with the Azure CLI or portal, then export an ARM template and convert that into a Bicep file to build that environment. This is especially helpful if you have an existing environment already set up in Azure.

az group export --name {YourResourceGroupName} > template_export.arm
az bicep decompile --file template_export.arm

You can also export the arm template from the Azure portal or pick and choose which resources to export from the CLI.

2. Deploy into a Limited Azure Environment

In reality, this is a risk management strategy and not a developer efficiency tip. However, if you wreck an environment once and have to recreate it, this tip can turn into developer efficiency. While developing your Bicep file, resist the urge to deploy it into an existing environment. Instead, at least use an isolated resource group. Better yet, use a separate subscription or even a different Azure Active Directory. This will help ensure your existing environments are safe and sound until you are ready to deploy your tested updates.

3. Deploy from Your Local Environment

It goes without saying that the faster you get feedback, the faster you can make adjustments. Making changes and sending them through a CI/CD build pipeline can be very time-consuming. Instead, set up to run your Azure CLI deployment command from your local environment. This will cut the time required to test changes significantly. Once you are satisfied with your Bicep file, integrate it with your CI/CD pipelines.

4. Use Modules

Modules are external files that encapsulate setting up resources. These make your files easier to read and make logic reusable. You can then use these modules for other deployments or create failover resources.

5. Use Parameters Liberally

Parameters make your Bicep files more flexible. This gives you options when you need to establish a new environment. Maybe you need a unique environment that mimics your production environment, but you don’t want to pay for that expensive database. Parameters give you the knobs to control these types of decisions. Also, you should include as many logical defaults as possible for your parameters.

As a starting point, it is a good idea to ensure the following items are configurable:

• Location, Subscription, and Resource Group
• Resource Names – defaults use a standard pattern, allow for different prefixes and postfixes or unique names
• SKU tiers
• Users and Groups
• Passwords and Keys – never defaults, could generate

6. Create a Params File

Your Bicep file is now full of parameters. However, you now have to set all of those parameters. This will fill up your terminal with all sorts of command line parameters. Finding, adding, and removing certain parameters from a large list on the command line is a pain. Instead, create a params file and start using it for your testing. This will help you manage and visualize all of your new parameters. It also gives you a jumpstart on preparing the different files for your CI/CD deployments.

Don’t forget that for your CI/CD pipelines, your sensitive data like passwords should not be in the params file but instead come from your pipelines secrets repository.

7. Run Often

Even running from your local environment, running most deployments takes at least a couple of minutes. Therefore, writing a large chunk of your Bicep file and then testing it can seem like a good idea. However, because Bicep deployment errors are not very good (but getting better), this can cause headaches trying to figure out what failed. Instead, write a small chunk and test it. Then, if you encounter an error, you have a much easier time figuring out what went wrong.

Don’t remove your resources in Azure between tests to offset the longer deployment times. Bicep is designed to create and update. Keeping your resources in Azure means you don’t have to go through as many resource creations each time you run. Save time by avoiding creating resources over and over.