launchdarkly-flag-targeting

LaunchDarkly 标志定向与发布

您正在使用一个技能，它将引导您完成更改功能标志的受众。您的工作是了解标志的当前状态，确定用户所需的正确定向方法，安全地进行更改，并验证最终状态。

先决条件

此技能需要在您的环境中配置远程托管的 LaunchDarkly MCP 服务器。

必需的 MCP 工具：

• get-flag：在进行更改前了解当前状态
• toggle-flag：在环境中打开或关闭标志的定向
• update-rollout：更改默认规则（fallthrough）的变体或百分比发布
• update-targeting-rules：添加、删除或修改自定义定向规则
• update-individual-targets：添加或删除个体定向中的特定用户/上下文

可选的 MCP 工具：

• copy-flag-config：将定向配置从一个环境复制到另一个环境
• create-approval-request：当直接更改被阻止时创建审批请求
• list-approval-requests：检查标志的待处理审批请求
• apply-approval-request：应用已批准的审批请求

核心概念：评估顺序

在进行任何定向更改之前，请理解 LaunchDarkly 如何评估标志。这决定了您的更改实际效果：

1. 标志关闭 -> 向所有人提供 offVariation。其他都不重要。
2. 个体定向 -> 如果上下文匹配特定的目标列表，则提供该变体。优先级最高。
3. 自定义规则 -> 从上到下评估规则。第一个匹配的规则生效。
4. 默认规则（fallthrough） -> 如果没有其他匹配，则提供此变体或发布。

这意味着：如果您添加了定向规则但标志关闭，则没有人会看到更改。如果您在默认规则上设置了百分比发布但存在个体定向，则该定向用户绕过发布。

工作流程

步骤 1：了解当前状态

在更改任何内容之前，检查已配置的内容。

1. 确认环境。 不指定环境的“打开它”是模糊的。始终确认用户指的是哪个环境。默认询问而不是假设。
2. 获取标志。 使用 get-flag 并指定目标环境以查看：
   • on：定向当前是否启用？
   • fallthrough：默认规则是什么？（变体或百分比发布）
   • offVariation：标志关闭时提供什么？
   • rules：是否有任何自定义定向规则？
   • targets：是否有任何个体定向的用户/上下文？
   • prerequisites：是否有任何依赖的标志？
3. 评估复杂性。 没有规则和个体定向的标志很简单。具有多个规则、目标和先决条件的标志需要更加小心。

步骤 2：确定正确的方法

根据用户的需求和您发现的情况，选择合适的工具和策略。请参阅定向模式获取完整参考。

常见场景：

用户想要	工具	备注
“打开它”	toggle-flag 使用 on: true	最简单的更改
“关闭它”	toggle-flag 使用 on: false	向所有人提供 offVariation
“发布到 X%”	update-rollout 使用 rolloutType: "percentage"	权重必须总和为 100
“为 Beta 用户启用”	update-targeting-rules：添加带有子句的规则	规则内部是 AND，规则之间是 OR
“添加特定用户”	update-individual-targets	最高优先级，覆盖所有规则

在编写规则、个体定向或百分比发布之前，请确认上下文支持它。 如果规则中命名的上下文种类或属性在标志评估中不存在，则规则静默地永远不会匹配；个体定向匹配上下文的键，而不是像电子邮件这样的属性；发布只能按标志读取时存在的种类进行分桶。请参阅上下文可用性以选择实际会触发的上下文。
| “完全发布” | update-rollout 使用 rolloutType: "variation" | 向所有人提供一种变体 |
| “从 staging 复制” | copy-flag-config | 将测试过的配置推广到生产环境 |

步骤 3：运行安全检查清单

在应用更改之前，尤其是在生产环境中，请运行安全检查清单。关键检查：

1. 正确的环境？ 再次确认您正在针对预期的环境。
2. 需要审批？ 某些环境需要审批工作流。如果任何变更工具返回 requiresApproval: true：
   • 告知用户此环境需要审批。
   • 如果提供了 approvalUrl，请分享。
   • 提供使用 create-approval-request 创建审批请求的选项，使用相同的指令（在响应的 instructions 字段中返回）。
   • 不要尝试绕过审批或自动批准。
   • 请参阅审批工作流了解完整流程。
3. 先决条件标志？ 如果此标志有先决条件，则必须满足这些条件，定向才能按预期工作。
4. 规则排序影响？ 如果添加规则，请考虑它们在评估顺序中的位置。规则从上到下评估，第一个匹配的生效。
5. 包含注释。 始终添加审计跟踪注释，尤其是对于生产环境的更改。

步骤 4：应用更改

使用适当的工具进行更改。关键说明：

• toggle-flag：指定 on: true 或 on: false、env 和 comment。
• update-rollout：使用 rolloutType: "percentage" 和人类友好的权重（例如 80 表示 80%），权重总和为 100；或使用 rolloutType: "variation" 和 variationIndex。
• update-targeting-rules：指令支持 addRule、removeRule、updateRuleVariationOrRollout、addClauses、removeClauses、reorderRules。
• update-individual-targets：指令支持 addTargets、removeTargets、addContextTargets、removeContextTargets、replaceTargets。

请参阅定向模式获取详细的指令示例。

步骤 5：验证

应用更改后，确认结果：

1. 获取更新后的标志。 再次使用 get-flag 验证新状态。
2. 确认用户期望的内容。 用通俗语言描述最终的定向：
   • “该标志现在在生产环境中打开，向 25% 的用户提供 true，向 75% 的用户提供 false。”
   • “Beta 用户现在看到变体 A。其他所有人获得默认值（变体 B）。”
3. 检查副作用。 如果存在规则或个体定向，请确保更改与它们正确交互。

处理需要审批的环境

当任何变更工具返回 requiresApproval: true 时，直接更改被阻止，因为环境需要审批。请按照审批工作流参考执行：

1. 创建审批请求 使用 create-approval-request，并使用被阻止响应中的 instructions
2. 告知用户 有关待处理的审批，并分享审批请求详情
3. 稍后检查审批状态 如果请求，使用 list-approval-requests
4. 应用请求 使用 apply-approval-request，一旦审阅者批准（reviewStatus 为 "approved"）
5. 验证结果 应用后使用 get-flag

重要上下文

• update-rollout 使用人类友好的百分比。 传递 80 表示 80%，而不是 80000。该工具处理内部权重转换。
• 权重必须总和为 100。 对于百分比发布，所有变体的权重必须恰好总计为 100。
• 规则排序很重要。 规则从上到下评估。重新排序规则可以在不更改任何单个规则的情况下改变行为。
• 个体定向优先级最高。 它们覆盖所有规则和默认值。将某人添加为个体定向意味着规则不适用于他们。
• “已发布”的标志仍然打开。 状态为“已发布”的标志向所有人提供单一变体。如果您想移除该标志，请使用清理技能，而不是定向更改。

参考

• 定向模式：发布策略、规则构建、个体定向和跨环境复制
• 上下文可用性：规则、目标或发布可以使用哪些上下文种类/属性——将种类与标志读取的表面匹配，键与属性，以及发布分桶
• 安全检查清单：更改前验证、审批工作流、环境意识
• 审批工作流：创建、检查和应用审批请求