# Rollen und Module versionieren

<p class="callout info">Zielgruppe: Betreuer · Stand: 06.11.2026</p>

Terraform-Module und Ansible-Rollen werden unterschiedlich versioniert. Module haben Versionslinien, Rollen nur zwei Branches. Kompatibilität entsteht immer im Modul, nie in der Rolle.

## Ansible-Rollen

- Zwei Branches: `latest` (Default, Entwicklung) und `stable` (Konsum). Es gibt keine Tags.
- Module binden Rollen immer auf `stable`.
- Eine Rolle bekommt keine Aliase oder Fallbacks für alte Variablennamen.

## Terraform-Module

- Versionslinien als Branches `<major>.<minor>`, z. B. `0.3`. Jeder Merge in den Linien-Branch veröffentlicht die nächste Patchversion.
- Stacks pinnen eine Linie, z. B. `~> 0.3.1` bzw. `>= 0.3.1, < 0.4.0`.
- Ein inkompatibler Umbau bekommt eine neue Linie (z. B. `0.2` → `0.3`). Die alte Linie bleibt für den Bestand.
- Die gerenderten Ansible-Requirements (`requirements.*.yml`) erzeugt ein CI-Job im Modul. Er pusht selbst einen Commit.

## Kompatibilität bei Umbenennungen

1. Die Rolle benennt Variablen einfach um, ohne Alias.
2. Das Modul übergibt alte **und** neue Namen nebeneinander an das Playbook.
3. Geht das nicht, entsteht eine neue Modul-Linie.
4. Modul-MRs werden gemergt, **bevor** die Rolle auf `stable` kommt.

Globale Kontext-Variablen (`site`, `stage`, `role_slug`, `state`, `checkmk_server`) bleiben ohne Präfix.

## Stolperfallen

<p class="callout warning">Das Anlegen eines neuen Linien-Branches veröffentlicht sofort <code>X.Y.0</code> mit dem Inhalt der Vorgängerlinie. Diese Version nicht verwenden, erst ab <code>X.Y.1</code> pinnen.</p>

- Ein Modul, das eine Rolle auf einen Feature-Branch pinnt, hängt an diesem Branch. Den Branch nicht löschen oder force-pushen, bevor das Modul umgestellt ist.
- Nach einer Änderung an CI-Variablen auf den Folgecommit des Requirements-Jobs achten.

## Weiterführend

- [Merge heißt Deploy](https://docs.squeeze.one/books/developer-good-practice/page/merge-heisst-deploy)