Mitglied werden – KI-Tutor mit vollen Antworten

Training Module

Feature Flags & Progressive Delivery: Risk Tagging, Canary-Steuerung & Rollback ohne Deploy

Zwei bestehende Module erwähnen Feature Flags bisher nur als Stichpunkt: DevOps Monitoring ordnet sie knapp in die Feedbackschleife zwischen CI/CD und Umsatzwirkung ein, das DevSecOps-Prinzip Produktionsnähe nennt “Feature Flags mit Risk Tagging” als ein Umsetzungsbeispiel von dreien, ohne eigene Vertiefung. Dieses 135-Minuten-Modul holt genau das nach. Im Konzeptteil lernt ihr die vier Flag-Grundmuster (Release-, Ops-, Permission- und Experiment-Flag) unterscheiden und ein Risk-Tagging-Schema kennen: jede Flag bekommt eine Risikostufe, einen verantwortlichen Owner und eine Canary-Quote, bevor sie überhaupt live geschaltet werden darf. Im Hands-on-Block arbeitet ihr gegen einen mitgelieferten, minimalen Flask-Flag-Service: zuerst repariert ihr eine Konfigurationsdatei, die das Risk-Tagging-Schema verletzt (der Service verweigert sonst den Start), dann steuert ihr die Canary-Quote eines Flags zur Laufzeit, und zum Schluss simuliert ihr einen Incident: eine erhöhte Fehlerquote im Canary-Cohort löst automatisiert den Kill-Switch aus. Der Rollback ist dabei ein einzelner Request an den weiterlaufenden Prozess, kein Redeploy, kein Neustart. Zum Abschluss ordnet ihr das Zusammenspiel mit Observability-Signalen ein, ohne den Observability-Stack selbst erneut aufzubauen.

Academy Briefing vereinbaren

Oder sofort per Mail an mail@mhm-dl.de

Format

135 Minuten, live (remote oder vor Ort), Input & ein vollständiger Hands-on-Block gegen einen mitgelieferten, minimalen Flask-Flag-Service

Teilnehmende

DevOps-Engineers, Entwickler:innen und Teamleitungen, die Feature Flags als Risiko- und Rollout-Steuerung statt nur als An/Aus-Schalter einsetzen wollen

Voraussetzungen

Kein eigener Cloud-Account nötig: alles läuft lokal. Python 3 und curl lokal verfügbar; CI/CD-Grundverständnis hilfreich, keine Pflicht

Warum dieses Training für deine Organisation wirkt

Zwei Stichpunkte, eine eigenständige Vertiefung

Wo DevOps Monitoring und Produktionsnähe Feature Flags bislang nur nennen, bekommen sie hier ein eigenes Modul mit Risk-Tagging-Schema, Canary-Steuerung und einem vollständigen Kill-Switch-Hands-on.

Rollback als Request, nicht als Redeploy

Der mitgelieferte Flag-Service läuft während der gesamten Übung durchgehend weiter. Der Kill-Switch ist ein einzelner POST-Request an den laufenden Prozess, live reproduzierbar, nicht nur behauptet.

Risk Tagging als Startbedingung, nicht als Nachgedanke

Der Service verweigert den Start, wenn eine Flag das Risk-Tagging-Schema verletzt (fehlende Risikostufe, fehlender Owner, ungültige Canary-Quote): Governance, die technisch erzwungen statt nur dokumentiert wird.

Was Teilnehmende mitnehmen

  • Die vier Flag-Grundmuster unterscheiden: Release-Flag (unfertigen Code sicher ausliefern), Ops-Flag (Betriebsschalter, z. B. Kill-Switch), Permission-Flag (Zugriff je Nutzersegment) und Experiment-Flag (A/B-Test).
  • Ein Risk-Tagging-Schema je Flag entwerfen: Risikostufe (niedrig/mittel/hoch), verantwortlicher Owner und Canary-Quote, und begründen, warum eine höhere Risikostufe eine niedrigere Start-Quote nahelegt.
  • Ein verletztes Risk-Tagging-Schema in einer Konfigurationsdatei gegen eine vorgegebene Fehlerliste reparieren und den Unterschied zu einer rein dokumentierten (statt technisch erzwungenen) Governance-Regel benennen.
  • Die Canary-Quote eines Flags zur Laufzeit per API verändern und die deterministische Cohort-Zuordnung (treatment/control) nachvollziehen.
  • Einen simulierten Incident (erhöhte Fehlerquote im Canary-Cohort) erkennen und den Kill-Switch auslösen, danach live bestätigen, dass der Prozess durchgehend weiterlief und kein Redeploy nötig war.
  • Das Zusammenspiel mit Observability-Signalen einordnen: welche Kennzahl aus DevOps Monitoring einen Kill-Switch-Trigger auslösen würde, ohne den Observability-Stack selbst erneut aufzubauen.

Für wen dieses Modul ideal ist

  • • DevOps-Engineers, die Feature Flags aus den Stichpunkt-Erwähnungen in DevOps Monitoring und Produktionsnähe jetzt hands-on vertiefen wollen
  • • Entwickler:innen, die ein Risk-Tagging-Schema für eigene Feature Flags einführen wollen, statt Flags ungetaggt zu verteilen
  • • Teamleitungen, die einen Kill-Switch-Mechanismus als Rollback-Weg ohne Redeploy verstehen und einordnen wollen

Rahmendaten

  • • Dauer: 135 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, ein vollständiger Hands-on-Block gegen einen mitgelieferten Flask-Flag-Service
  • • Voraussetzungen: Kein eigener Cloud-Account nötig, Python 3 und curl lokal verfügbar, CI/CD-Grundverständnis hilfreich

Modulaufbau & Agenda

  1. Kick-off & Abgrenzung (10 min): Format, Ablauf und Abgrenzung zu DevOps Monitoring (dort Feature Flags nur ein Stichpunkt in der Business-Monitoring-Feedbackschleife) und zu Kubernetes Progressive Delivery (dort Canary/Blue-Green als Cluster-Infrastruktur mit Argo Rollouts, hier Canary-Steuerung auf Anwendungsebene ohne Kubernetes).

  2. Flag-Grundmuster (20 min): Release-, Ops-, Permission- und Experiment-Flag unterscheiden, je ein Praxisbeispiel, Abgrenzung zum reinen Konfigurationsschalter ohne Rollout-Steuerung.

  3. Risk Tagging (20 min): Risikostufe, Owner und Canary-Quote als Pflichtfelder, Zusammenhang zwischen Risikostufe und sinnvoller Start-Quote, Abgrenzung zu rein dokumentierter (nicht technisch erzwungener) Governance.

  4. Hands-on: Flag-Service & Kill-Switch (45 min, Hands-on): den mitgelieferten Flask-Flag-Service gegen eine Konfigurationsdatei starten, die das Risk-Tagging-Schema verletzt (Service verweigert den Start), die Datei reparieren, die Canary-Quote eines Flags per API verändern, einen simulierten Incident (erhöhte Fehlerquote im Canary-Cohort) erkennen und per Kill-Switch beenden, Abgleich mit der mitgelieferten Musterlösung.

  5. Zusammenspiel Observability/Canary (25 min): welche Kennzahl aus DevOps Monitoring (Fehlerquote, Latenz, Error Budget) einen Kill-Switch-Trigger realistisch auslösen würde, und warum ein Canary-Rollout eine Beobachtungsphase statt eines Alles-oder-nichts-Deployments braucht.

  6. Fazit (15 min): Zusammenfassung Flag-Grundmuster, Risk-Tagging-Schema und Kill-Switch-Mechanismus, Einordnung von Feature Flags als eigenständiger Risiko- und Rollout-Steuerungsmechanismus neben Observability und Infrastruktur-Canary, offene Fragen, Kontaktmöglichkeit.

Abgrenzung: Dieses Modul behandelt bewusst keine Kubernetes-/Cluster-Infrastruktur für Canary- oder Blue-Green-Rollouts (dafür Kubernetes Progressive Delivery — Canary & Blue-Green mit Argo Rollouts), keinen vollständigen Observability-Stack-Aufbau (dafür DevOps Monitoring), und kein produktionsreifes Feature-Flag-Produkt (LaunchDarkly, Unleash, Flagsmith o. Ä.): der mitgelieferte Flag-Service ist ein didaktisch minimales Trainings-Beispiel ohne Persistenz oder Authentifizierung, ausdrücklich nicht für den produktiven Einsatz gedacht.

Hands-on Inhalte (Auszug)

Risk-Tagging-Schema reparieren

  • Flag-Service startet nicht, weil eine Flag das Schema verletzt: konkrete Fehlerliste als Ausgangspunkt
  • Fehlende Risikostufe anhand der Flag-Beschreibung begründet ergänzen
  • Abgleich mit der mitgelieferten Musterlösung

Canary-Quote steuern

  • Deterministische Cohort-Zuordnung (treatment/control) je Nutzer-ID nachvollziehen
  • Canary-Quote eines Flags per API-Aufruf zur Laufzeit erhöhen
  • Keine Codeänderung, kein Redeploy für eine Rollout-Steuerung nötig

Simulierter Incident

  • Erhöhte, synthetisch simulierte Fehlerquote im Canary-Cohort erkennen
  • Schwellenwert-Entscheidung: wann ein Trigger für den Kill-Switch gerechtfertigt ist
  • Stellvertretend für ein echtes Observability-Signal, ohne eigene Monitoring-Infrastruktur

Kill-Switch: Rollback ohne Deploy

  • Ein POST-Request schaltet die Flag für alle Nutzer sofort ab
  • Derselbe Prozess läuft davor und danach unverändert weiter, kein Neustart, kein Redeploy
  • Live-Bestätigung: 0 Nutzer landen nach dem Kill-Switch noch im Canary-Cohort

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zur erfolgreichen Schema-Reparatur, Zeit vom simulierten Incident bis zum ausgelösten Kill-Switch) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen das Risk-Tagging-Schema und die Incident-Simulation auf eure tatsächliche Flag-Landschaft an.

Academy Briefing anfragen