Release-Hygiene: Versionierung, Changelogs, Feature Flags.
Release Hygiene: Versionierung, Changelogs, Feature Flags
Releases sind keine technische Aktion. Sie sind Kommunikation – an Nutzer, ans Team, ans System.
Was Release Hygiene bedeutet
Nicht: möglichst selten deployen. Sondern: deployen, wann man will, mit klarer Kommunikation darüber, was sich ändert.
Schlechte Release Hygiene sieht so aus: niemand weiß genau, was in diesem Deployment drin ist. Es gibt keine Versionsnummer. Das Changelog ist leer. Und wenn was kaputt ist, weiß keiner, was geändert wurde.
Semantic Versioning (SemVer)
MAJOR.MINOR.PATCH – das ist das universelle Schema. PATCH für Bug Fixes, MINOR für neue Features (rückwärtskompatibel), MAJOR für Breaking Changes. Für interne Web-Apps ist das manchmal zu förmlich – aber auch dort ist eine Versionierung hilfreich.
Changelogs
Keep a Changelog (keepachangelog.com) ist der Standard-Template. Einträge kategorisiert in: Added, Changed, Deprecated, Removed, Fixed, Security. Jeder Eintrag in verständlicher Sprache, nicht als Git-Commit-Shortcode.
Automatisierung: Conventional Commits als Commit-Convention, dann automatisiert Changelogs generieren (semantic-release, conventional-changelog).
Feature Flags
Feature Flags entkoppeln Deployment von Feature-Rollout. Code deployen, Feature noch nicht aktivieren. Dann: nach erfolgreicher Verifikation für 10% der Nutzer aktivieren, dann 50%, dann 100%.
Das reduziert das Deployment-Risiko massiv. Und erlaubt schnelles Rollback ohne Code-Revert.
Checkliste Release Hygiene
Versionierungsschema definiert und genutzt
Changelog gepflegt (mindestens bei Major/Minor-Releases)
Conventional Commits oder ähnliche Convention eingeführt
Feature Flags für neue, risikoreiche Features
Rollback-Strategie definiert
Release-Notes für Endnutzer (wenn B2C oder B2B-Portal)
Release-Prozess professionalisieren?
markom.digital hilft beim Aufbau von Release-Workflows – von Conventional Commits bis Feature-Flag-Integration.
