Flags und Arten

Ein Flag ist eine benannte Entscheidung, die deine App von FortressFlag treffen lässt: Soll dieses Gerät den neuen Checkout sehen? Welche Beschriftung bekommt der Kaufen-Button? Wie viele Wiederholungen, bevor wir aufgeben? Diese Seite gibt dir das Vokabular, auf dem der Rest der Dokumentation aufbaut.

Flags leben in einem Projekt und haben pro Umgebung einen Wert

Jedes Flag gehört zu einem Projekt und wird über seinen Key identifiziert — einen kurzen Namen in Kleinbuchstaben wie new-checkout. Der Key ist das, wonach dein Code fragt, und er ist nach dem Anlegen unveränderlich: Deine ausgelieferten Apps haben den Key fest in ihren Code eingebaut, ein Umbenennen würde sie also kaputt machen. Den Anzeigenamen eines Flags kannst du jederzeit ändern; der Key bleibt für immer.

Ein Flag hat nicht einen Wert — es hat einen Wert pro Umgebung. new-checkout kann in dev an sein, in staging im Rollout und in production aus, alles gleichzeitig. Du schaltest und targetest jede Umgebung unabhängig.

Die drei Arten

Jedes Flag hat eine Art, die beim Anlegen gewählt wird und danach unveränderlich ist:

Art	Werte	Gut für
Boolean	true / false	Kill-Switches, Feature-Gates, Rollouts
String	Benannte Textvarianten	Textexperimente, Algorithmusauswahl, Themes
Number	Benannte Zahlenvarianten	Limits, Timeouts, Schwellenwerte

Die Art ist aus demselben Grund unveränderlich wie der Key: Dein Code liest das Flag über einen typisierten Aufruf (isEnabled, stringValue, numberValue), und ein Flag, das unter einer ausgelieferten App seine Art wechselt, würde für sie keinen Sinn mehr ergeben.

Varianten

String- und Number-Flags liefern Varianten — benannte Werte wie control → "buy-now" und treatment → "start-free". Die Namen sind für dich und dein Dashboard; die Geräte deiner Nutzer erhalten immer nur den Wert. Variantennamen verlassen die Management-Ebene nie.

Standards, und der Standard hinter dem Standard

Zwei verschiedene Dinge heißen Standard, und es lohnt sich, sie auseinanderzuhalten:

• Der Standard des Flags ist das, was eine Umgebung liefert, wenn keine Targeting-Regel greift. Bei einem Boolean-Flag ist das sein An/Aus-Zustand; bei einem multivariaten Flag die Variante, die du als Standard wählst.
• Der Standard deines Codes ist der Wert, den du an der Aufrufstelle übergibst — isEnabled("new-checkout", default: false). Das ist das Ende der Fallback-Kette: das, was deine App verwendet, wenn sie FortressFlag noch nie erreicht hat oder wenn das Flag in dieser Umgebung nicht existiert (oder keinen Wert zum Liefern hat).

Ein brandneues multivariates Flag ohne gewählte Standardvariante liefert nichts — der Standard deines Codes antwortet, bis du dich entscheidest. Das ist Absicht: Ein Flag, das du noch nicht fertig konfiguriert hast, soll sich verhalten wie ein Flag, das es nicht gibt.

Der Lebenszyklus: archivieren, wiederherstellen, endgültig löschen

Ein Flag zu löschen ist umkehrbar — bis zu einem gewissen Punkt. Archivieren entfernt es aus deinen Apps: Auf jedem Online-Gerät hört das Flag innerhalb von etwa einer Minute auf, aufgelöst zu werden, und die Standards deines Codes übernehmen. Ein archiviertes Flag kann innerhalb der Aufbewahrungsfrist unversehrt wiederhergestellt oder danach endgültig gelöscht werden. Die Archivliste liegt in jedem Projekt, direkt neben den Flags, die es enthält.

Wenn ein Flag 90 Tage lang unberührt geblieben ist, markiert das Dashboard es als veraltet — ein Anstoß, es zu archivieren, nie ein automatisches Archivieren. Flags, die du vergessen hast, sind Komplexität, für die deine Codebasis weiterhin bezahlt.

Wie geht es weiter?

• Targeting — Regeln, Segmente und Prozent-Rollouts
• Umgebungen und Projekte — wo Flags leben
• Wie Flags deine App erreichen — was ein Gerät tatsächlich empfängt