环境与项目

FortressFlag 里的一切由两条轴组织起来：项目按代码库或产品划分你的 flag，环境按部署阶段划分每个 flag 的值。你的 dev 构建从 dev 环境读取 new-checkout；你已发布的应用从 production 读取它。同一个 flag，各自独立的值。

环境由你来定义

每个组织一开始都有三个预置环境——dev、staging 和 production——你可以创建、重命名和删除自己的环境，最多 12 个。一个 QA 环境、按地区成对的环境、一个 canary——只要贴合你的部署方式。

管理环境（创建、重命名、重新分类、删除）是 Admin 及以上的操作。当仍有有效的 SDK 密钥在对某个环境进行身份验证时，你不能删除它——一个你的应用还在读取的环境，不能被从它们脚下抽走。

让一个环境成为“生产”的不是它的名字——而是生产类别，一个由 Admin 勾选的复选框。这个类别才是驱动各项保护的东西：

在那里写入 flag 需要更高的角色。Developer 可以整天自由地切换非生产环境；而生产类别的环境只接受来自 Admin 和 Owner 的直接写入。（Developer 仍然可以提议生产变更，交给队友批准——见角色与安全。）
控制台会用醒目的样式标出它，这样没有人会把生产环境当成 staging 来编辑。

因为它是类别而不是名字，你可以有多个生产类别的环境——比如 production-eu 和 production-us——每一个都获得同样的保护。而把一个环境标记为生产类别，本身就是一次会被审计的 Admin 级操作，因为它改变了谁可以在那里写入。

Flag、细分的目标和 SDK 密钥都住在一个项目里。一个组织可以容纳很多项目——每个应用一个、每个团队一个，随你怎么切分工作。每个项目有自己的 flag 列表、自己的归档和自己的 SDK 密钥。

Admin 和 Owner 看得到每个项目。Viewer 和 Developer 只看得到被授予的项目——访问是一份按成员的白名单，由 Admin 管理。

有一个细节值得知道，免得它让你意外：一个成员未被授予的项目，会表现得像不存在一样——返回的是未找到，而不是“无权访问”的错误。一个成员无法枚举那些没有给他的项目名称。如果一位队友说某个项目不见了，先检查他的访问授权，再看别的。