定向

默认情况下，一个环境向每台设备提供 flag 的默认值。定向就是你向某些设备提供别的东西的方式：beta 测试者、某个特定的应用版本、所有人中的 10%。本页解释这台机器；灰度指南带你一步步用起来。

标签：规则看到的东西

规则检验标签——关于发起请求的那台设备的一些小的键/值事实。SDK 会自动发送几个内置标签（appVersion、appBuild、osVersion、platform、sdkVersion），你的应用也可以加上自己的，比如 cohort: "beta"。

关于标签有两件事值得尽早知道：

• 标签被评估后就被遗忘。FortressFlag 用它们回答它们所到达的那一次请求，然后丢弃——它们从不被存储，也从不被记录到日志。任何地方都没有标签历史，这是设计使然。
• 标签是你的应用的声明。一个标签可以携带你的代码放进去的任何东西——所以不要把机密或你用户的个人数据放进标签值里。让它们只承载分组、版本和配置。

规则：一个有序列表，首个匹配即生效

每个 flag + 环境都有一个有序的规则列表。一条规则是一组用 AND 连接的条件——cohort 是 beta 且 appVersion ≥ 2.0——加上匹配时它所提供的值。

评估过程很简单，值得内化：

1. 规则从上到下依次检查。
2. 第一条所有条件都成立的规则决定值。它下面的规则一概不看——顺序就是含义，你可以在控制台里重新排序规则。
3. 针对设备没有发送的标签的条件不成立。没有标签，就没有匹配——这条规则被跳过，绝不会报错。
4. 如果没有规则匹配，就提供 flag 的默认值。

一条没有条件的规则总是匹配——那就是你放在列表底部的“其他所有人”形态。

版本比较

条件可以比较版本：appVersion ≥ 2.0。版本按点号拆分，从左到右按数值比较，缺失的部分按零处理——所以 2.0 等于 2.0.0，2.10 比 2.9 新。一个无法解析为点分数字的设备版本（比如 2.0-beta）只会让条件不成立。不支持预发布后缀——请比较纯粹的点分版本。

细分：一段你命名并复用的规则

一个细分是一个有名字的 AND 条件列表——beta-testers、internal-devices——你为整个组织定义一次，然后在跨 flag、跨环境的规则里引用它。编辑这个细分，每一条使用它的规则都会跟着变。

正是这种影响范围，使得编辑细分需要生产级权限：一个被生产规则引用的细分，一旦改变就是在改变生产环境，无论是谁保存的。

百分比灰度

任何规则都可以带一个灰度百分比：它不再匹配所有通过其条件的设备，而只匹配其中最前面的 N%。“10% 的 beta 测试者”就是这样实现的——先过条件，再过百分比这道门。

三个特性让灰度可以放心依赖：

• 粘性。一台设备是否落在这个百分比之内，是由设备的标识和 flag 的 key 计算出来的——同一台设备在每次请求中都得到同样的答案。没有人会在灰度里忽进忽出，而把 10% 提高到 20% 时，最初的 10% 仍然在内。
• 按 flag 独立。计算中混入了 flag 的 key，所以一个 flag 上的 10% 灰度和另一个 flag 上的 10% 灰度抓到的是你设备群里不同的十分之一。不存在永远倒霉、一次接下所有实验的那 10% 设备。
• 什么都不存。分组归属是纯粹的算术，每次请求重新计算——FortressFlag 不保存任何关于哪些设备在哪个灰度里的记录。没有什么可泄露，也没有什么需要清理。

限制

宽裕到你通常碰不到，固定下来是为了让负载保持有界：每个 flag 每个环境最多 20 条规则，每条规则 5 个条件（一个细分引用算一个，它自己最多可以容纳 10 个），标签键最长 64 个字符，条件值最长 256 个。

接下来去哪

• 设置百分比灰度——这项任务，一步一步来
• 环境与项目——定向是按环境的
• Flag 如何到达你的应用——为什么设备永远看不到你的规则