๐Ÿ’ช Azure Bicep CI/CD ๐Ÿš€

Hey, you. You’re not manually deploying your Azure Bicep Infrastructure as Code, are you?!? Let’s prevent that next production outage, help your team collaborate on changes, and enable more frequent deployments. In this post, I’ll outline what tooling is available to integrate Bicep in your pipelines, and some good practices for building and deploying.

Resources to get started

If you’re new to Azure Bicep, I’d recommend checking out the Microsoft Learn learning path for Bicep. There are also great resources for the basics on Deploying Bicep files by using GitHub Actions and Integrating Bicep with Azure Pipelines. Once you have the fundamentals covered, you may find the remainder of this post helpful.



I’m going to break things down into 2 phases of the pipeline: 1. build 2. deploy. For the build phase, we have multiple options for tooling:

Good Practices

I like to set up the build phase early in my pipeline, in order to fail fast and speed up the feedback loop. The build should make sure 3 things happen:

  • Ensure transpilation (conversion to ARM template) is successful.
  • Ensure linting rules pass. Configure bicepconfig.json to throw an error on important rule violations.
  • Ensure preflight validaton is successful.

To combine all of the above using a single command, validation commands can be used. For a resource group deployment, I can use the Azure CLI command az deployment group validate or Azure PowerShell’s Test-AzResourceGroupDeployment.

For an example of this using GitHub Actions, check out my SpaceGameVNext’s pipeline here.



Similar to build, we have multiple options for deployment:

Good Practices

I like to promote the same set of templates for all environments (dev -> test -> prod). This encourages the DRY (Don’t repeat yourself) principle. In order to make this happen, I can:


For an example of this using GitHub Actions, check out my SpaceGameVNext’s pipeline here.


None of this is hard and fast guidance to follow strictly. There are many different types of architectures, environments, repository structures, etc. These are things that I’ve found success with and YMMV. What have you found success in while integrating Bicep into your pipelines? I would love to hear your thoughts in the comments.

3 thoughts on “๐Ÿ’ช Azure Bicep CI/CD ๐Ÿš€

  1. This is a great blog post Marcus, thanks for posting!

    I tend to use the CLI tasks for my deployments (Iโ€™ve been using your repo mentioned above as a starting point) and it works really well

    Few questions if I may:

    1) What are your opinions on testing the templates, is there a tool similar to the ARM-TTK coming for bicep? Testing for things like out of date API versions etc

    2) I like the subscription scope deployment, but doing it that way means missing out on switching from incremental/complete modes when needed, to remove resources that are no longer in the template, like you can do with a RG scope. Is something like that coming soon?


    1. Thanks, Paul!

      1. The Bicep linter shifts more validations left, into VS Code while you’re authoring templates. We’re working to meet parity with all of the arm-ttk tests that make sense. We’ve had quite a few ideas submitted for linting rules (see here). Beyond IDE tests, I’d recommend leveraging pre-flight validation and what-if, as mentioned above.

      2. The ARM Deployments team is working on a new feature called Deployment Stacks that will improve resource lifecycle management. It should be in private preview soon!

      1. Thanks for replying Marcus, Iโ€™m just going to stick with the linter now then as it works a treat so far

        Iโ€™m looking forward to testing out deployment stacks. I can imagine more people are moving towards subscription scope deploys now, so this will prove very useful!

Leave a Reply

Your email address will not be published. Required fields are marked *