Platform Versioning and Upgrades

The platform's Terraform modules keep changing: security fixes, new features, provider upgrades. Workloads depend on them. Versioning means every change is released as an explicit version, every deployment chooses which version it uses, and nobody's deployment changes without an MR.

• 3-Tier Terraform Module Taxonomy
• Vulnerability Management

Status: releases in place, upgrade process planned

Modules are released automatically with semantic versions. Deployments take up new versions by hand. There is no automated update tooling or published upgrade schedule yet.

---

How modules are released (in place)

On merge to main, the module pipeline's release job works out the next version from the commit messages since the last tag, tags it, and publishes a GitLab release:

Commit type	Version change	Example
feat:	Minor	v1.2.3 → v1.3.0
fix:	Patch	v1.2.3 → v1.2.4
A breaking change (! or BREAKING CHANGE:)	Major	v1.2.3 → v2.0.0
chore, docs, refactor only	No release	—

A change that should reach deployments must be committed as feat: or fix:. Anything else ships nothing.

How deployments use versions (in place)

Every module is referenced with a pinned tag:

source = "git::https://gitlab.com/grinntec-cloud/terraform-modules/terraform-solutions/solution-manage-azure-subscription.git?ref=v8.1.8"

• Never use a branch (?ref=main) or leave out ref. The deployment would change without an MR.
• Solutions pin their own modules, so taking up a solution version brings a tested set of module versions with it.
• Provider constraints stay at azurerm ~> 4.0, azuread ~> 3.0 and gitlab ~> 17.0 in modules. The lock file in each deployment fixes the exact version.

---

Upgrading (planned)

Change	What deployments do	Timescale
Patch (fixes)	Bump the tag, check the plan shows only the expected change, merge	Within 30 days. Within the fix deadline for security fixes.
Minor (new features, compatible)	Bump when the feature is needed, or at the next change	When convenient
Major (breaking)	Follow the release's upgrade notes. These may include moved {} blocks and changes to inputs.	Planned together, usually per quarter

Making it easier

• Renovate (or GitLab dependency updates) can open an MR in every deployment when a new module tag or provider version is released. Each MR runs a plan, so reviewers see the effect straight away.
• Release notes for every major version: what changed, why, and the exact steps to upgrade.
• Declarative refactoring: a major version that renames or moves resources ships moved {} blocks, so upgrades don't destroy and recreate them. See the module taxonomy.
• Support window: the platform supports the current and previous major version of each solution. Deployments on older versions are asked to upgrade.

Knowing who is behind

Every resource carries IaCModule and IaCModuleVersion tags (see the tagging standard). An Azure Resource Graph query on those tags shows which deployments run which module versions, without reading every repository:

resources
| where isnotempty(tags.IaCModule)
| summarize Resources = count() by Module = tostring(tags.IaCModule), Version = tostring(tags.IaCModuleVersion)
| order by Module asc, Version desc