Entornos y proyectos
Dos ejes organizan todo en FortressFlag: los proyectos separan tus flags por base de
código o producto, y los entornos separan el valor de cada flag por etapa de despliegue.
Tu build de app dev lee new-checkout del entorno dev; tu app publicada lo lee de
producción. El mismo flag, valores independientes.
Los entornos los defines tú
Sección titulada «Los entornos los defines tú»Cada organización empieza con tres entornos de serie — dev, staging y production — y
puedes crear, renombrar y eliminar los tuyos, hasta 12. Un entorno de QA, un par por región,
un canary — lo que encaje con cómo despliegas.
Gestionar entornos (crear, renombrar, reclasificar, eliminar) es una acción de Admin o superior. No puedes eliminar un entorno mientras haya claves SDK activas que se autentiquen contra él — un entorno que tus apps todavía están leyendo no se puede eliminar debajo de ellas.
La clase producción — no el nombre
Sección titulada «La clase producción — no el nombre»Lo que hace que un entorno sea «producción» no es su nombre — es la clase producción, una casilla que marca un Admin. La clase es lo que activa las salvaguardas:
- Escribir flags ahí exige un rol más alto. Los Developers cambian entornos que no son de producción libremente todo el día; un entorno de clase producción acepta escrituras directas solo de Admins y Owners. (Los Developers pueden seguir proponiendo cambios en producción para que un compañero los apruebe — mira Roles y seguridad.)
- El panel lo muestra de forma llamativa, para que nadie edite producción pensando que es staging.
Como es una clase y no un nombre, puedes tener varios entornos de clase producción —
digamos, production-eu y production-us — y cada uno recibe las mismas salvaguardas. Y
marcar un entorno como de clase producción es en sí mismo un acto auditado de nivel Admin,
porque cambia quién puede escribir ahí.
Proyectos
Sección titulada «Proyectos»Los flags, los objetivos de los segmentos y las claves SDK viven dentro de un proyecto. Una organización puede tener muchos — uno por app, uno por equipo, como quieras repartir tu trabajo. Cada proyecto tiene su propia lista de flags, su propio archivo y sus propias claves SDK.
El acceso a proyectos es una lista de permitidos
Sección titulada «El acceso a proyectos es una lista de permitidos»Los Admins y los Owners ven todos los proyectos. Los Viewers y los Developers ven solo los proyectos que se les han concedido — el acceso es una lista de permitidos por miembro, gestionada por los Admins.
Un detalle que conviene conocer para que nunca te sorprenda: un proyecto que no se le ha concedido a un miembro responde como si no existiera — un «no encontrado», no un error de «sin acceso». Un miembro no puede enumerar nombres de proyectos que no se le dieron. Si un compañero dice que falta un proyecto, revisa sus concesiones de acceso antes que nada.
¿Por dónde seguir?
Sección titulada «¿Por dónde seguir?»- Roles y seguridad — quién puede hacer qué, y las salvaguardas de producción
- Claves — las claves SDK están limitadas a un proyecto + entorno
- Invita a tu equipo — las concesiones se fijan en la propia invitación