Zum Inhalt springen
FortressFlag Docs

Umgebungen und Projekte

Zwei Achsen ordnen alles in FortressFlag: Projekte teilen deine Flags nach Codebasis oder Produkt, und Umgebungen teilen den Wert jedes Flags nach Deployment-Stufe. Dein dev-App-Build liest new-checkout aus der dev-Umgebung; deine ausgelieferte App liest es aus der Produktion. Dasselbe Flag, unabhängige Werte.

Umgebungen definierst du selbst

Abschnitt betitelt „Umgebungen definierst du selbst“

Jede Organisation startet mit drei vorbereiteten Umgebungen — dev, staging und production — und du kannst eigene anlegen, umbenennen und löschen, bis zu 12. Eine QA-Umgebung, ein Paar pro Region, ein canary — was immer zu deiner Art zu deployen passt.

Umgebungen zu verwalten (anlegen, umbenennen, neu einstufen, löschen) ist eine Aktion für Admin und höher. Du kannst eine Umgebung nicht löschen, solange sich noch aktive SDK-Schlüssel gegen sie authentifizieren — eine Umgebung, die deine Apps noch lesen, lässt sich ihnen nicht unter den Füßen wegziehen.

Die Produktionsklasse — nicht der Name

Abschnitt betitelt „Die Produktionsklasse — nicht der Name“

Was eine Umgebung zur „Produktion“ macht, ist nicht ihr Name — es ist die Produktionsklasse, ein Häkchen, das ein Admin setzt. Die Klasse ist es, die die Schutzmaßnahmen antreibt:

  • Flags dort zu schreiben erfordert eine höhere Rolle. Developers schalten Nicht-Produktionsumgebungen den ganzen Tag frei um; eine Umgebung mit Produktionsklasse nimmt direkte Schreibzugriffe nur von Admins und Owners an. (Developers können Produktionsänderungen weiterhin vorschlagen, damit ein Teammitglied sie genehmigt — siehe Rollen und Sicherheit.)
  • Das Dashboard stellt sie auffällig dar, damit niemand die Produktion bearbeitet und dabei denkt, es sei Staging.

Weil es eine Klasse und kein Name ist, kannst du mehrere Umgebungen mit Produktionsklasse haben — etwa production-eu und production-us — und jede bekommt dieselben Schutzmaßnahmen. Und eine Umgebung als Produktionsklasse zu markieren ist selbst ein auditierter Akt auf Admin-Ebene, weil er ändert, wer dort schreiben darf.

Projekte

Abschnitt betitelt „Projekte“

Flags, die Ziele von Segmenten und SDK-Schlüssel leben in einem Projekt. Eine Organisation kann viele davon haben — eines pro App, eines pro Team, wie auch immer du deine Arbeit aufteilst. Jedes Projekt hat seine eigene Flag-Liste, sein eigenes Archiv und seine eigenen SDK-Schlüssel.

Projektzugriff ist eine Allowlist

Abschnitt betitelt „Projektzugriff ist eine Allowlist“

Admins und Owners sehen jedes Projekt. Viewers und Developers sehen nur die Projekte, die ihnen zugeteilt wurden — Zugriff ist eine Allowlist pro Mitglied, verwaltet von Admins.

Ein Detail, das du kennen solltest, damit es dich nie überrascht: Ein Projekt, das einem Mitglied nicht zugeteilt wurde, antwortet, als existiere es nicht — ein Nicht-gefunden, kein „Kein Zugriff“-Fehler. Ein Mitglied kann keine Projektnamen aufzählen, die es nicht bekommen hat. Wenn jemand aus dem Team sagt, ein Projekt fehle, prüf zuerst die Zugriffsfreigaben, bevor du irgendetwas anderes tust.

Wie geht es weiter?

Abschnitt betitelt „Wie geht es weiter?“