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. 開關為 OFF -> 對所有人提供 offVariation。其他設定都不重要。
2. 個別目標 -> 如果情境符合特定的目標清單，則提供該變體。優先級最高。
3. 自訂規則 -> 從上到下評估規則。第一個符合的規則獲勝。
4. 預設規則（fallthrough） -> 如果沒有其他規則符合，則提供此變體或逐步推出。

這表示：如果您新增了一個目標規則但開關是 OFF，沒有人會看到變更。如果您在預設規則上設定了百分比逐步推出，但存在個別目標，則該目標使用者會繞過逐步推出。

工作流程

步驟 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	優先級最高，覆蓋所有規則

在編寫規則、個別目標或百分比逐步推出之前，請確認情境支援它。 一個規則如果指定了開關評估中不包含的情境種類或屬性，則會靜默地永遠不匹配；個別目標是匹配情境的 key，而不是像 email 這樣的屬性；而逐步推出只能根據讀取開關時存在的情境種類進行分桶。請參閱情境可用性來選擇一個實際上會觸發的情境。
| 「全面推出」 | update-rollout 搭配 rolloutType: "variation" | 對所有人提供一個變體 |
| 「從 staging 複製」 | copy-flag-config | 將測試過的設定推廣到正式環境 |

步驟 3：執行安全檢查清單

在套用變更之前，特別是在正式環境中，請執行安全檢查清單。關鍵檢查項目：

1. 正確的環境？ 再次確認您正在對目標環境進行操作。
2. 需要核准？ 某些環境需要核准流程。如果任何變更工具回傳 requiresApproval: true：
   • 告知使用者此環境需要核准。
   • 如果提供了 approvalUrl，請分享該 URL。
   • 提議使用 create-approval-request 搭配相同的 instructions（從回應的 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：instructions 支援 addRule、removeRule、updateRuleVariationOrRollout、addClauses、removeClauses、reorderRules。
• update-individual-targets：instructions 支援 addTargets、removeTargets、addContextTargets、removeContextTargets、replaceTargets。

請參閱目標設定模式以取得詳細的 instruction 範例。

步驟 5：驗證

套用變更後，請確認結果：

1. 取得更新後的開關。 再次使用 get-flag 來驗證新狀態。
2. 確認使用者的預期。 用白話文描述最終的目標設定：
   • 「開關現在在正式環境中為 ON，對 25% 的使用者提供 true，對 75% 的使用者提供 false。」
   • 「Beta 使用者現在看到變體 A。其他所有人獲得預設值（變體 B）。」
3. 檢查副作用。 如果存在規則或個別目標，請確保變更與它們正確互動。

處理需要核准的環境

當任何變更工具回傳 requiresApproval: true 時，表示直接變更被阻擋，因為該環境需要核准。請依照核准流程參考文件進行：

1. 建立核准請求：使用 create-approval-request 搭配被阻擋回應中的 instructions
2. 告知使用者：關於待處理的核准，並分享核准請求的詳細資訊
3. 稍後檢查核准狀態：如果使用者要求，使用 list-approval-requests 查看
4. 套用請求：一旦審核者核准（reviewStatus 為 "approved"），使用 apply-approval-request 套用
5. 驗證結果：套用後使用 get-flag 確認

重要情境

• update-rollout 使用人類友善的百分比。 傳入 80 代表 80%，而不是 80000。工具會處理內部的權重轉換。
• 權重總和必須為 100。 對於百分比逐步推出，所有變體的權重總和必須恰好為 100。
• 規則排序很重要。 規則從上到下評估。重新排序規則可以在不變更任何單一規則的情況下改變行為。
• 個別目標的優先級最高。 它們會覆蓋所有規則和預設值。將某人加入為個別目標表示規則不適用於他們。
• 「已啟動」的開關仍然是 ON。 狀態為「launched」的開關是對所有人提供單一變體。如果您想要移除開關，請使用清理技能，而不是目標設定變更。

參考資料

• 目標設定模式：逐步推出策略、規則建構、個別目標設定以及跨環境複製
• 情境可用性：規則、目標或逐步推出可以使用哪些情境種類/屬性——將種類與讀取開關的表面匹配、key 與屬性的區別，以及逐步推出的分桶方式
• 安全檢查清單：變更前驗證、核准流程、環境意識
• 核准流程：建立、檢查和套用核准請求