Ga naar inhoud
FortressFlag Docs

Omgevingen en projecten

Twee assen organiseren alles in FortressFlag: projecten verdelen je flags per codebase of product, en omgevingen verdelen de waarde van elke flag per deploystadium. Je dev-appbuild leest new-checkout uit de dev-omgeving; je uitgebrachte app leest hem uit productie. Dezelfde flag, onafhankelijke waarden.

Omgevingen definieer je zelf

Section titled “Omgevingen definieer je zelf”

Elke organisatie begint met drie voorgezaaide omgevingen — dev, staging en production — en je kunt er zelf aanmaken, hernoemen en verwijderen, tot 12. Een QA-omgeving, een paar per regio, een canary — wat maar past bij hoe jij deployt.

Omgevingen beheren (aanmaken, hernoemen, herclassificeren, verwijderen) is een actie voor Admin en hoger. Je kunt een omgeving niet verwijderen zolang er nog actieve SDK-sleutels tegen authenticeren — een omgeving waar je apps nog uit lezen laat zich niet onder ze vandaan verwijderen.

De productieklasse — niet de naam

Section titled “De productieklasse — niet de naam”

Wat een omgeving “productie” maakt is niet haar naam — het is de productieklasse, een vinkje dat een Admin zet. De klasse is wat de waarborgen aandrijft:

  • Daar flags schrijven vereist een hogere rol. Developers schakelen de hele dag vrij in niet-productieomgevingen; een omgeving met productieklasse accepteert directe schrijfacties alleen van Admins en Owners. (Developers kunnen productiewijzigingen nog steeds voorstellen zodat een teamgenoot ze goedkeurt — zie Rollen en veiligheid.)
  • Het dashboard maakt hem nadrukkelijk zichtbaar, zodat niemand productie bewerkt in de veronderstelling dat het staging is.

Omdat het een klasse is en geen naam, kun je meerdere omgevingen met productieklasse hebben — zeg production-eu en production-us — en elk krijgt dezelfde waarborgen. En een omgeving als productieklasse markeren is zelf een geaudite actie op Admin-niveau, omdat het verandert wie er mag schrijven.

Projecten

Section titled “Projecten”

Flags, de doelen van segmenten en SDK-sleutels leven binnen een project. Eén organisatie kan er veel bevatten — één per app, één per team, hoe je je werk ook indeelt. Elk project heeft zijn eigen flaglijst, zijn eigen archief en zijn eigen SDK-sleutels.

Projecttoegang is een allowlist

Section titled “Projecttoegang is een allowlist”

Admins en Owners zien elk project. Viewers en Developers zien alleen de projecten die hun zijn toegekend — toegang is een allowlist per teamlid, beheerd door Admins.

Eén detail dat het weten waard is, zodat het je nooit verrast: een project dat een gebruiker niet is toegekend antwoordt alsof het niet bestaat — een not-found, geen “geen toegang”-fout. Een gebruiker kan geen projectnamen opsommen die hij niet heeft gekregen. Zegt een teamgenoot dat een project ontbreekt, controleer dan eerst de toegangsrechten.

Waar nu heen?

Section titled “Waar nu heen?”