百分比部署使您可以向一小部分用户逐步发布某项功能。任何目标定位规则都可以包含介于 0 和 100 之间的部署百分比。
当您希望限制影响范围 (blast radius)、运行实验或对请求进行采样而无需部署新代码时，请使用百分比部署。
当一条规则具有百分比部署时，只有在该规则条件和部署分桶均匹配时，该规则才会提供其变体。不匹配该规则的上下文会继续到下一条规则，或者如果后续没有匹配的规则，则接收默认变体。
例如，一条规则可以定位 enterprise 计划中的用户，然后只向这些用户的 10% 提供新体验。不在这 10% 内的用户将继续进入规则列表的其余部分。
{
"priority": 1,
"conditions": [
{ "attribute": "plan", "operator": "equals", "value": "enterprise" }
],
"serve_variation": "on",
"rollout": {
"percentage": 10,
"attribute": "userId"
}
}当百分比部署提供变体时，评估详细信息中的 reason 为 SPLIT。
Flagship 使用对可配置属性的一致性哈希将用户分配到部署存储桶 (rollout bucket)。对于给定的部署配置，同一用户始终接收相同的标志值。这确保了跨重复评估的一致体验。
默认情况下，分桶属性是 targetingKey。您可以在仪表板中设置部署时配置要用于分桶的属性。
部署分桶在账户和标志之间是独立的。相同的标识符可能由于不同的标志而落入不同的存储桶，这有助于避免不相关功能之间的关联部署。
根据应保持稳定的内容选择分桶属性：
| 用例 | 建议属性 |
|---|---|
| 面向用户的发布 | 稳定的用户 ID 或 targetingKey |
| 账户级别的部署 | 账户 ID |
| 组织级别的部署 | 组织或工作区 ID |
| 请求级别的采样 | 请求 ID 或其他每个请求专属的值 |
对于大多数功能发布和实验，请使用稳定的用户或账户标识符。仅当在请求之间发生变化是可以接受的（例如流量采样）时，才使用请求级别的值。
从较小规模的部署开始，监控您的应用程序，然后随着信心的增长而增加百分比。
- 以 5% 的部署规模创建标志。
- 监控错误、延迟、产品指标和用户反馈。
- 增加到 25%，然后到 50%，最后到 100%。
- 在部署达到 100% 后，移除临时目标定位规则并使获胜变体成为默认变体。
- 功能完全发布后，删除旧代码路径并删除该标志。
假设有一个具有以下规则的标志 new-checkout：
- 规则 1：
plan equals "enterprise"— 提供变体on。 - 规则 2：在
userId上的 25% 部署 — 提供变体on。 - 默认变体：
off。
在此配置中：
- 所有企业用户都会看到新的结账流程。
- 其他所有用户的 25%（由其
userId决定）也会看到新的结账流程。 - 其余 75% 的非企业用户看到标准的结账流程。
随着信心的增加，提高部署百分比，直到达到 100%。
对于没有任何受众条件的纯 A/B/n 测试，请在 Cloudflare 仪表板中配置每个变体的流量份额。仪表板会为您计算累积阈值。
如果您直接通过 API 管理纯 A/B/n 测试，请为每个变体创建一个带累积部署百分比的规则。Flagship 按照优先级顺序评估规则。如果上下文与规则匹配，但未落入该规则的部署百分比内，则评估将继续进行到下一条规则。
在变体 A、B 和 C 之间以 30% / 40% / 30% 进行拆分：
| 变体 | 份额 | 累积阈值 |
|---|---|---|
| A | 30% | 30 |
| B | 40% | 70 |
| C | 30% | 100 |
[
{
"priority": 1,
"conditions": [],
"serve_variation": "variant-a",
"rollout": { "percentage": 30, "attribute": "targetingKey" }
},
{
"priority": 2,
"conditions": [],
"serve_variation": "variant-b",
"rollout": { "percentage": 70, "attribute": "targetingKey" }
},
{
"priority": 3,
"conditions": [],
"serve_variation": "variant-c",
"rollout": { "percentage": 100, "attribute": "targetingKey" }
}
]在 API 管理的配置中，第一条规则涵盖了 0-30 号存储桶。第二条规则涵盖 31-70。最后一条规则覆盖剩余的到 100 为止的存储桶。如果每个合格的上下文都应接收某个变体，则始终将最后一条规则设置为 100。
在实验的每条规则中使用相同的分桶属性。如果每条规则使用不同的属性，则用户可能无法留在预期的划分中。
您可以将受众定位与多变体部署相结合。例如，您可能希望只有高级用户（premium users）进入实验，然后将这些高级用户分为三个变体。
对于定向的 A/B/n 测试，在每个变体规则上重复相同的受众条件，并使用累积的部署阈值。当您使用这种定向的多规则模式时，无论是使用仪表板还是 API，都需明确配置每条规则的累积阈值。
对于仅限高级用户（premium-only）的划分，其中 20% 接收变体 A，40% 接收变体 B，其余 40% 接收变体 C，使用的阈值为 20、60 和 100：
[
{
"priority": 1,
"conditions": [
{ "attribute": "plan", "operator": "equals", "value": "premium" }
],
"serve_variation": "variant-a",
"rollout": { "percentage": 20, "attribute": "targetingKey" }
},
{
"priority": 2,
"conditions": [
{ "attribute": "plan", "operator": "equals", "value": "premium" }
],
"serve_variation": "variant-b",
"rollout": { "percentage": 60, "attribute": "targetingKey" }
},
{
"priority": 3,
"conditions": [
{ "attribute": "plan", "operator": "equals", "value": "premium" }
],
"serve_variation": "variant-c",
"rollout": { "percentage": 100, "attribute": "targetingKey" }
}
]不匹配 plan equals "premium" 的用户会跳过所有三条规则，并接收标志的默认变体，除非后续的规则与他们匹配。
通过选择每次请求 (per-request) 的分桶属性，您可以使用百分比部署进行请求级别的采样。例如，1% 的部署可以为一小部分请求启用额外的日志记录或诊断。
仅当同一用户在不同的请求中收到不同的结果是可以接受的时候，才使用此模式。
如果同一用户在不同请求中收到不同的值，则评估上下文可能缺少 targetingKey 或配置的分桶属性。
在每次评估中传递相同的稳定标识符：
const enabled = await env.FLAGS.getBooleanValue("gradual-rollout", false, {
userId: session.user.id,
});然后将部署配置为由 userId 进行分桶。
检查规则顺序。优先级数字较低的包罗万象规则 (catch-all rule) 可以在后续部署规则运行之前返回变体。请将宽泛的包罗万象规则置于较特定的规则之后。
对于普通的受仪表板管理的 A/B/n 测试，请输入每个变体的流量份额，并让仪表板计算阈值。
对于 API 管理的 A/B/n 测试，或对于配置为多条规则的定向 A/B/n 测试，请使用累积阈值。30% / 40% / 30% 的划分应使用 30、70 和 100 作为阈值，而不是 30、40 和 30。
当上下文匹配了规则条件但未落入部署百分比以内，且后续没有规则与其匹配时，就可能发生这种情况。如果每个匹配的上下文都应收到非默认变体，请添加一条后续规则，或者使用 100% 作为最后规则的比例。