Targeting

Standardmäßig liefert eine Umgebung jedem Gerät den Standard des Flags. Targeting ist, wie du manchen Geräten etwas anderes lieferst: Betatestern, einer bestimmten App-Version, 10 % von allen. Diese Seite erklärt die Maschine; die Rollout-Anleitung führt dich durch die Benutzung.

Tags: was Regeln sehen

Regeln prüfen Tags — kleine Schlüssel/Wert-Fakten über das anfragende Gerät. Die SDKs senden ein paar eingebaute Tags automatisch (appVersion, appBuild, osVersion, platform, sdkVersion), und deine App kann eigene hinzufügen, etwa cohort: "beta".

Zwei Dinge über Tags solltest du früh wissen:

• Tags werden ausgewertet und vergessen. FortressFlag benutzt sie, um die eine Anfrage zu beantworten, mit der sie ankamen, und verwirft sie dann — sie werden nie gespeichert und nie geloggt. Es gibt nirgends eine Tag-Historie, mit Absicht.
• Tags sind Behauptungen deiner App. Ein Tag kann alles tragen, was dein Code hineinlegt — leg also keine Geheimnisse oder personenbezogenen Daten deiner Nutzer in Tag-Werte. Beschränk sie auf Kohorten, Versionen und Konfiguration.

Regeln: eine geordnete Liste, der erste Treffer gewinnt

Jedes Flag + Umgebung hat eine geordnete Liste von Regeln. Eine Regel ist eine Gruppe von Bedingungen, mit UND verknüpft — cohort ist beta UND appVersion ≥ 2.0 — plus der Wert, den sie bei einem Treffer liefert.

Die Auswertung ist einfach und lohnt sich zu verinnerlichen:

1. Regeln werden von oben nach unten geprüft.
2. Die erste Regel, deren Bedingungen alle zutreffen, entscheidet den Wert. Nichts darunter wird mehr befragt — die Reihenfolge ist Bedeutung, und du kannst Regeln im Dashboard umsortieren.
3. Eine Bedingung auf einem Tag, das das Gerät nicht gesendet hat, trifft nicht zu. Kein Tag, kein Treffer — die Regel wird übersprungen, nie ein Fehler.
4. Wenn keine Regel greift, liefert der Standard des Flags.

Eine Regel ohne Bedingungen trifft immer zu — das ist die „alle anderen“-Form, die du ans Ende einer Liste setzt.

Versionsvergleiche

Bedingungen können Versionen vergleichen: appVersion ≥ 2.0. Versionen werden an Punkten getrennt und numerisch verglichen, von links nach rechts, und fehlende Komponenten zählen als null — 2.0 ist also gleich 2.0.0, und 2.10 ist neuer als 2.9. Eine Geräteversion, die sich nicht als punktgetrennte Zahlen lesen lässt (etwa 2.0-beta), lässt die Bedingung einfach nicht zutreffen. Pre-Release-Suffixe werden nicht unterstützt — vergleiche einfache punktgetrennte Versionen.

Segmente: ein Regelteil, den du benennst und wiederverwendest

Ein Segment ist eine benannte UND-Liste von Bedingungen — beta-testers, internal-devices —, die du einmal für deine ganze Organisation definierst und aus Regeln über Flags und Umgebungen hinweg referenzierst. Bearbeite das Segment, und jede Regel, die es benutzt, folgt.

Genau diese Reichweite ist der Grund, warum das Bearbeiten eines Segments Produktionsberechtigung erfordert: Ein Segment, das von einer Produktionsregel referenziert wird, ändert die Produktion, wenn es sich ändert — egal, wer es speichert.

Prozent-Rollouts

Jede Regel kann einen Rollout-Prozentsatz tragen: Statt jedes Gerät zu treffen, das ihre Bedingungen erfüllt, trifft sie nur die ersten N % davon. So funktioniert „10 % der Betatester“ — erst die Bedingungen, dann das Prozent-Gate.

Drei Eigenschaften machen Rollouts verlässlich:

• Sticky. Ob ein Gerät innerhalb des Prozentsatzes liegt, wird aus der Identität des Geräts und dem Key des Flags berechnet — dasselbe Gerät bekommt bei jeder Anfrage dieselbe Antwort. Niemand flackert in einen Rollout hinein und wieder heraus, und wer 10 % auf 20 % erhöht, behält die ursprünglichen 10 % drin.
• Pro Flag. Die Berechnung mischt den Flag-Key hinein, sodass ein 10-%-Rollout auf einem Flag und ein 10-%-Rollout auf einem anderen verschiedene Zehntel deiner Flotte erwischen. Es gibt keine dauerhaft unglücklichen 10 % der Geräte, die jedes Experiment auf einmal abbekommen.
• Nichts wird gespeichert. Kohortenzugehörigkeit ist reine Arithmetik, pro Anfrage neu berechnet — FortressFlag führt keine Aufzeichnung darüber, welche Geräte in welchem Rollout sind. Es gibt nichts, was leaken könnte, und nichts aufzuräumen.

Limits

Großzügig genug, dass du ihnen normalerweise nicht begegnest, fest, damit Payloads begrenzt bleiben: bis zu 20 Regeln pro Flag pro Umgebung, 5 Bedingungen pro Regel (eine Segmentreferenz zählt als eine und kann bis zu 10 eigene enthalten), Tag-Schlüssel bis zu 64 Zeichen, Bedingungswerte bis zu 256.

Wie geht es weiter?

• Richte einen Prozent-Rollout ein — die Aufgabe, Schritt für Schritt
• Umgebungen und Projekte — Targeting ist pro Umgebung
• Wie Flags deine App erreichen — warum Geräte deine Regeln nie sehen