Environnements et projets
Deux axes organisent tout dans FortressFlag : les projets séparent vos flags par base de
code ou par produit, et les environnements séparent la valeur de chaque flag par étape
de déploiement. Votre build d’app dev lit new-checkout depuis l’environnement dev ; votre
app livrée le lit depuis production. Même flag, valeurs indépendantes.
Les environnements, c’est vous qui les définissez
Section intitulée « Les environnements, c’est vous qui les définissez »Chaque organisation démarre avec trois environnements préremplis — dev, staging et
production — et vous pouvez créer, renommer et supprimer les vôtres, jusqu’à 12. Un
environnement QA, une paire par région, un canary — ce qui correspond à votre façon de
déployer.
Gérer les environnements (créer, renommer, reclasser, supprimer) est une action réservée aux Admins et au-dessus. Vous ne pouvez pas supprimer un environnement tant que des clés SDK actives s’authentifient encore contre lui — un environnement que vos apps lisent encore ne peut pas être supprimé sous leurs pieds.
La classe production — pas le nom
Section intitulée « La classe production — pas le nom »Ce qui fait qu’un environnement est « production », ce n’est pas son nom — c’est la classe production, une case qu’un Admin coche. C’est la classe qui déclenche les protections :
- Y écrire des flags demande un rôle plus élevé. Les Developers basculent les environnements hors production librement toute la journée ; un environnement de classe production n’accepte les écritures directes que des Admins et des Owners. (Les Developers peuvent toujours proposer des changements en production qu’un coéquipier approuve — voir Rôles et sécurité.)
- Le tableau de bord lui donne un style voyant, pour que personne ne modifie la production en croyant être en staging.
Parce que c’est une classe et non un nom, vous pouvez avoir plusieurs environnements de
classe production — disons production-eu et production-us — et chacun reçoit les mêmes
protections. Et marquer un environnement comme classe production est lui-même un acte
audité, de niveau Admin, parce qu’il change qui a le droit d’y écrire.
Les projets
Section intitulée « Les projets »Les flags, les cibles des segments et les clés SDK vivent dans un projet. Une organisation peut en contenir plusieurs — un par app, un par équipe, comme vous découpez votre travail. Chaque projet a sa propre liste de flags, ses propres archives et ses propres clés SDK.
L’accès aux projets est une liste d’autorisation
Section intitulée « L’accès aux projets est une liste d’autorisation »Les Admins et les Owners voient tous les projets. Les Viewers et les Developers ne voient que les projets qui leur ont été accordés — l’accès est une liste d’autorisation par membre, gérée par les Admins.
Un détail à connaître pour qu’il ne vous surprenne jamais : un projet qu’un membre ne s’est pas vu accorder répond comme s’il n’existait pas — un « introuvable », pas une erreur « accès refusé ». Un membre ne peut pas énumérer les noms de projets qu’on ne lui a pas donnés. Si un coéquipier dit qu’un projet a disparu, vérifiez ses accès avant toute autre chose.
Où aller ensuite
Section intitulée « Où aller ensuite »- Rôles et sécurité — qui peut faire quoi, et les protections de la production
- Clés — les clés SDK sont limitées à un projet + un environnement
- Invitez votre équipe — les accès se définissent directement sur l’invitation