10 February 2022
If you've been using Azure Bicep to deploy your Azure resources you'll know its easy to write declarative code, easier than in say ARM. I would even go as far as saying its far more elegant than Terraform. However, it may have occurred that there is a major missing feature from Bicep that could make your life much harder. I’m talking about semantic versioning for modules.
Modules are reusable units of code that can be referenced by other Bicep files. They allow you to encapsulate common patterns and best practices into reusable components that can be shared across projects and teams. However, without semantic versioning, it is hard to manage dependencies and ensure compatibility between different versions of modules.
In this blog post, I will explain what semantic versioning is, why it is important for module management, and what are some of the current challenges and workarounds for using modules in Bicep. I will also share my hope that semantic versioning will be added soon to Bicep as it matures and evolves.
Semantic versioning is a formal convention for determining the version number of new software releases3. It consists of three numbers: major, minor, and patch. The major number indicates breaking changes that are not backward-compatible. The minor number indicates new features or enhancements that are backward-compatible. The patch number indicates bug fixes or improvements that do not affect functionality. At a glance a Semantic Versioned module helps convey to developers changes and expectations about a module's release.
Semantic versioning has many benefits for software development, such as keeping track of changes, ensuring compatibility, and simplifying updates1245. For example, if you use a library or a package that follows semantic versioning, you can easily see what kind of changes have been made in each release, whether you need to update your code to use it, and how to specify which version you want to use.
Currently, Bicep does not support specifying or enforcing semantic versions for modules. In fairness Bicep isn't alone, as of writing Terraform does not support Semantic Versioning either. This means that if you reference a module from another source (such as GitHub or Azure Template Specs), you have no way of knowing what version of the module you are using or whether it has changed since you last used it. This can lead to unexpected errors or inconsistencies when deploying your resources.
There are some workarounds for this limitation, such as using tags or branches to indicate versions in GitHub repositories3, or using different names or resource groups for different versions of template specs4. Terraform takes a similar approach infact the Terraform repository relies upon it. However, these solutions are not ideal and require manual intervention and coordination. A native support for semantic versioning in Bicep would make module management much easier and more reliable.
So given the importance and well understood benefit of Semantic Versioning why was Bicep developed without native support?
In conclusion, Azure Bicep is a great language for deploying Azure resources declaratively, but it lacks an important feature: semantic versioning for modules. This feature would enable developers to reuse modules more effectively and avoid deployment issues caused by incompatible changes. Hopefully, this feature will be added soon to Bicep as it matures and evolves.
In the meantime, this could be one workaround. https://itnext.io/automating-tagging-and-versioning-of-terraform-modules-or-any-language-3a271966c63c
コメント