Python-Quickstart

In ein paar Minuten wertet dein Python-Service Feature Flags in-process aus — kein Netzwerk-Hop pro Prüfung, keine Latenz in deinem Request-Pfad, eine Abfrage versorgt jeden Request, den dein Prozess bedient.

Null Abhängigkeiten: Das SDK ist reine Standardbibliothek, auf Python 3.11 und neuer. In einer asyncio-App funktioniert es genauso — die Auswertung ist eine schlichte In-Memory-Lesung, es gibt also nichts zu awaiten.

1. Installieren

Das SDK liegt in einem öffentlichen Repository auf GitHub — installiere es direkt von dort, auf das Release gepinnt:

pip install "git+https://github.com/FortressFlag/FortressFlag_SDK_python@v1.0.0"

Lässt du @v1.0.0 weg, folgst du stattdessen dem Branch development — praktisch, um einen Fix auszuprobieren, aber nicht das, was du in Produktion willst.

2. Der Server-Schlüssel — ein echtes Geheimnis

Dieses SDK benutzt einen Server-Schlüssel (ffs_…), und der ist das Gegenteil der Client-Schlüssel, die die Mobil- und Web-SDKs ausliefern: Er kann dein vollständiges Ruleset herunterladen, Targeting-Regeln inklusive. Behandle ihn genau wie ein Datenbankpasswort — eine Umgebungsvariable oder ein Secret-Manager, nie Code, nie ein Repository, nie ein Log. Die zwei Schlüsselklassen, nebeneinander.

3. Starte den Client

import os

import fortressflag

try:
    client = fortressflag.create(
        fortressflag.Configuration(key=os.environ["FF_SERVER_KEY"])
    )
except fortressflag.MalformedKeyError:
    # Die eine Stelle, an der das SDK raised: ein fehlerhafter Schlüssel, bevor irgendetwas ausliefert.
    raise SystemExit(1)

client.start(timeout=15.0)  # kehrt beim ersten Ruleset zurück (oder der Frist)

# ... dein Service läuft; Flag-Prüfungen sind jetzt In-Memory-Funktionsaufrufe.

start raised nie — wenn der erste Abruf nicht rechtzeitig landet, versucht der Client es auf seinem Hintergrund-Thread weiter, und deine Aufrufer bekommen inzwischen ihre Fallbacks. Der Poller ist ein Daemon-Thread: Er hindert deinen Interpreter nie am Beenden.

4. Werte ein Flag aus

enabled = client.bool_value(
    "new-checkout",
    fortressflag.Context(
        key="user-42",  # dein stabiler Kontext-Key: eine User-ID, eine Session-ID — deine Wahl
        tags={"cohort": "beta"},
    ),
    False,  # der Fallback, wenn das Flag unbekannt ist oder nie etwas abgerufen wurde
)

client.string_value und client.number_value funktionieren genauso. Der Kontext-key ist das, worauf Prozent-Rollouts bucketen — übergib denselben Bezeichner konsistent, und jeder Nutzer bekommt eine stabile Kohorte. Es sind deine Daten: Das SDK validiert, speichert oder loggt sie nie.

Das war’s — dein Service wertet Flags lokal aus. Eine Dashboard-Änderung erreicht jeden Prozess innerhalb von etwa einer Minute.

Die Auswertung schlägt nie fehl

bool_value, string_value und number_value antworten immer und raisen nie — ein Flag-Problem darf deinen Service niemals lahmlegen. Ein neu gestarteter Prozess liefert deine Fallbacks von der Aufrufstelle, bis sein erster Abruf landet (oder setz cache_path in der Konfiguration, um das letzte Ruleset in einer Datei deiner Wahl zu persistieren, und Neustarts setzen sofort daraus fort). Selbst ein widerrufener Schlüssel macht nichts kaputt: Das SDK wertet mit dem zuletzt heruntergeladenen Ruleset weiter aus, bis du ihm einen neuen Schlüssel gibst.

Wie geht es weiter?

• Wie Flags deine App erreichen — die Server-Plane, erklärt
• Schlüssel — ffs_-Schlüssel erstellen, rotieren und widerrufen
• Targeting — die Regeln, die dein Service jetzt auswertet