Ambienti e progetti

Due assi organizzano tutto in FortressFlag: i progetti dividono i tuoi flag per codebase o prodotto, e gli ambienti dividono il valore di ogni flag per fase di deploy. La build dev della tua app legge new-checkout dall’ambiente dev; l’app distribuita lo legge dalla produzione. Stesso flag, valori indipendenti.

Gli ambienti li definisci tu

Ogni organizzazione parte con tre ambienti preimpostati — dev, staging e production — e puoi crearne, rinominarne ed eliminarne di tuoi, fino a 12. Un ambiente QA, una coppia per regione, un canary — qualunque cosa rispecchi il modo in cui fai deploy.

Gestire gli ambienti (creare, rinominare, riclassificare, eliminare) è un’azione da Admin in su. Non puoi eliminare un ambiente finché chiavi SDK attive si autenticano ancora contro di esso — un ambiente che le tue app stanno ancora leggendo non si può eliminare da sotto i loro piedi.

La classe produzione — non il nome

Ciò che rende un ambiente «produzione» non è il suo nome — è la classe produzione, una casella che un Admin spunta. La classe è ciò che guida le salvaguardie:

• Scrivere flag lì richiede un ruolo più alto. I Developer attivano e disattivano gli ambienti non di produzione liberamente tutto il giorno; un ambiente di classe produzione accetta scritture dirette solo da Admin e Owner. (I Developer possono comunque proporre modifiche di produzione che un collega approva — vedi Ruoli e sicurezza.)
• La dashboard lo evidenzia vistosamente, così nessuno modifica la produzione credendo che sia lo staging.

Poiché è una classe e non un nome, puoi avere più ambienti di classe produzione — per esempio production-eu e production-us — e ognuno riceve le stesse salvaguardie. E contrassegnare un ambiente come classe produzione è a sua volta un atto registrato nell’audit e di livello Admin, perché cambia chi può scrivere lì.

Progetti

I flag, i target dei segmenti e le chiavi SDK vivono dentro un progetto. Un’organizzazione può contenerne molti — uno per app, uno per team, come preferisci suddividere il tuo lavoro. Ogni progetto ha il proprio elenco di flag, il proprio archivio e le proprie chiavi SDK.

L’accesso ai progetti è un’allowlist

Admin e Owner vedono ogni progetto. Viewer e Developer vedono solo i progetti che sono stati loro concessi — l’accesso è un’allowlist per membro, gestita dagli Admin.

Un dettaglio che vale la pena conoscere perché non ti sorprenda mai: un progetto non concesso a un membro risponde come se non esistesse — un «non trovato», non un errore di «accesso negato». Un membro non può enumerare i nomi dei progetti che non gli sono stati dati. Se un collega dice che un progetto manca, controlla i suoi permessi di accesso prima di ogni altra cosa.

Prossimi passi

• Ruoli e sicurezza — chi può fare cosa, e le salvaguardie della produzione
• Chiavi — le chiavi SDK hanno come ambito un progetto + un ambiente
• Invita il tuo team — i permessi si impostano direttamente sull’invito