How is everyone handling change management for their Infrastructure as a Code (IaC) projects?
Since we're treating infrastructure as code, that surely also applies to versioning and generating change logs? 😎
Problem statement
I'm deploying Azure resources using Bicep and Template Specs. I want to implement a a change management process, to improve reliability, collaboration, and governance.
A template spec is a resource type for storing an Azure Resource Manager template (ARM template) for later deployment, allowing you to share them with other users. It consists of a main template and any number of linked templates.
Template Specs support versioning. You can either update an existing version (for hotfixes) or publish a new version. You can choose to follow any versioning system, including semantic versioning.
Requirements:
Detailed History of Changes: Every change to the infrastructure code should be recorded, providing an audit trail of who made changes, when they were made, and why. This will ensure full accountability and traceability, critical in large, distributed teams.
Version Control and Tagging: With each change to the service, version numbers should be automatically increased according to Semantic Versioning, based on information provided by developers. Provisioned resources must be tagged with new versions, making it easy to identify which configuration is currently deployed across different environments. Template Specs version should be calculated automatically based on the new versions of the included resources.
Approval Workflows: Changes must be reviewed by the appropriate stakeholders (e.g., DevOps engineers, security teams) before being applied. During publishing time, versions should be automatically increased, and change logs should be generated, based on the changes included in the release.
Seamless CI/CD Integration: The process should seamlessly integrate with CI/CD pipelines, automating the deployment process from code commit to infrastructure provisioning.
Release Monitoring: It must be possible to monitor releases and track the deployment of infrastructure changes in real-time, providing insights into which version of the infrastructure is running in different environments and ensuring smooth transitions from one version to the next.
The approach
Using a structured change management process, such as Rush.io, in Infrastructure as Code (IaC) projects offers a range of advantages that help improve reliability, collaboration, and governance.
And although it's primarily designed for monorepos and JavaScript / TypeScript projects, it's versatile and can be adapted for other types of projects as well.
I've been using it in both my code and infrastructure-as-code (IaC) projects for years now, and I think it works like a charm. It requires minimal initial configuration and lets you enforce the same rules you'd typically set for pull requests, version bumps, and changelog generation.
Let's get started: Rush configuration
Top comments (0)