Triage Ops

1. 你在這里:
2. 極狐 Handbook
3. 極狐研發團隊
4. Triage Ops

• 即時類自動化操作
  • 提醒類
    • 提醒添加類型標記
    • 提醒添加詳細子標記
    • 提醒合并請求不要自動關閉 Bug 類型議題
    • 提醒用戶為將就緒狀態的合并請求相關聯的議題添加 ~"workflow::in review" 標記
    • 提醒用戶為議題添加緊急程度標簽
  • 便捷類
    • 自動補全父級標記
    • 給合并請求自動添加關聯議題的類型標記
    • 議題關閉時自動移除流程標記
    • 議題指派 QA 成員時自動添加 ~"workflow::in qa"
    • 自動為議題添加 ~"workflow::in dev" 標記
  • 流程類
    • 自動為社區類型議題分配 PM
    • Bug 類型議題處理
    • Feature Flag 被更改類型議題處理
    • 安全審查
      • 安全審查準備處理
      • 安全審查批準處理
      • 安全審查批準失效處理
  • 命令類
    • request_review 命令
• 周期類自動化操作
  • 工作報告
    • 里程碑回顧報表
  • 里程碑過渡
    • 自動為合并請求補全里程碑
    • 自動通知發開同事填寫 Capacity Planning
    • 自動通知開發同事處理 Milestone 遺留任務
    • 自動通知開發同事填寫 Milestone 的回顧反饋
    • 自動關閉 Time tracking 議題
• 參與貢獻

Triage Ops 是一個研發流程自動化項目，通過機器人 @jihulab-bot 自動處理研發流程上的工作，項目開源在：gitlab-cn/quality/triage-ops

自動化操作主要分為兩類：“即時類自動化操作” 和 “周期類自動化操作”。

即時類自動化操作

“即時類自動化操作” 就是機器人 @jihulab-bot 對用戶在 GitLab 實例上的動作，做出即時的響應操作。因為這些響應都是實時的，能很有效的增加用戶的體驗。

提醒類

提醒添加類型標記

類型標記是每個議題/合并請求的基本信息，有必要提醒作者添加類型標記。

• 自動化條件：
  • 發生事件：創建議題/合并請求
  • 議題/合并請求所屬分組為：gitlab-cn
  • 議題/合并請求作者所屬分組為：gitlab-cn
  • 議題/合并請求為開放狀態
  • 議題/合并請求沒有添加類型標記
  • 議題/合并請求沒有添加特殊例外標記：~"release", ~"QA", ~"Time tracking", ~"featureflag::changed" 等，所有情況見配置文件：config/jihu_labels.yml
  • 事件項目不是這些：gitlab-cn/developer-guide
• 自動化操作：
  • 給議題/合并請求添加評論，提醒作者添加類型標記
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/type_label_reminder.rb

提醒添加詳細子標記

• 自動化條件：
  • 發生事件：創建、更新議題/合并請求
  • 議題/合并請求所屬分組為：gitlab-cn
  • 議題/合并請求作者所屬分組為：gitlab-cn
  • 議題/合并請求為開放狀態
  • 議題/合并請求添加了需要子標記的標記，例如：~"type::feature", ~"type::maintenance" 等，所有情況見配置文件：config/jihu_labels.yml
• 自動化操作：
  • 給議題/合并請求添加評論，提醒作者添加詳細子標記
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/child_label_reminder.rb

提醒合并請求不要自動關閉 Bug 類型議題

• 自動化條件：
  • 發生事件：更新合并請求
  • 合并請求所屬分組為：gitlab-cn
  • 合并請求為開放狀態
  • 合并請求配置了自動關閉的議題
  • 合并請求配置的自動關閉議題有 ~"type::bug" 標記
• 自動化操作：
  • 給合并請求添加評論，提醒作者這類議題需要 QA 驗證才能關閉，不要使用 Closes #iid 這類關鍵字。
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/mr_close_bug_issue_reminder.rb
• 頻率限制：每個合并請求處理一次

提醒用戶為將就緒狀態的合并請求相關聯的議題添加 ~"workflow::in review" 標記

• 自動化條件：
  • 發生事件：更新合并請求、開啟合并請求
  • 合并請求所屬分組為：gitlab-cn
  • 合并請求為開放狀態
  • 合并請求的標題發生了變化
  • 合并請求的作者不是機器人用戶
  • 合并請求具有相關聯的議題
  • 合并請求處于就緒狀態
• 自動化操作：
  • 給合并請求添加評論，提醒作者為此合并請求相關聯的議題添加 ~"workflow::in review" 標記。
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/workflow_in_review_label_reminder.rb
• 頻率限制：每個合并請求最多處理一次

提醒用戶為議題添加緊急程度標簽

• 自動化條件：
  • 發生事件：更新議題、開啟議題
  • 議題所屬項目為：gitlab-cn/gitlab
  • 議題作者是 jihulab 群組 的直接成員
  • 議題作者不是 jihulab/engineering 群組 的直接成員
  • 議題具有 ~"type::bug" 或 ~"type::feature" 標記
  • 議題沒有 ~"CREQ:XXXX" 相關標記
• 自動化操作：
  • 提醒用戶為此議題添加 緊急程度標簽
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/creq_label_reminder.rb

便捷類

自動補全父級標記

有時議題/合并請求需要通過兩級標簽來對其分類，比如一個增加新功能的議題需要：~"type::feature" 和 ~"feature::addition"，這類情況其實像 ~"type::feature" 標記都可以交給 @jihulab-bot 來自動完成。

• 自動化條件：
  • 發生事件：創建、更新議題/合并請求
  • 議題/合并請求所屬分組為：gitlab-cn
  • 議題/合并請求為開放狀態
  • 議題/合并請求添加了有父級標記的標記，例如：~"feature::addition", ~"bug::mobile", ~"qa::pipeline" 等，所有情況見配置文件：config/jihu_labels.yml
• 自動化操作：
  • 給議題/合并請求補全缺失的父級標記
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/add_parent_label.rb

給合并請求自動添加關聯議題的類型標記

• 自動化條件：
  • 發生事件：創建、更新合并請求
  • 合并請求所屬分組為：gitlab-cn
  • 合并請求為開放狀態
  • 合并請求沒有添加類型標記
  • 合并請求有關聯議題
  • 合并請求的關聯議題有添加類型標記
• 自動化操作：
  • 給合并請求添加關聯議題的類型標記
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/apply_type_label_from_related_issue.rb

議題關閉時自動移除流程標記

• 自動化條件：
  • 發生事件：關閉議題
  • 議題所屬項目為：gitlab-cn/gitlab 或議題所屬群組為 jihulab/marketing/digital-experience
• 自動化操作：
  • 移除議題的流程標記(workflow label)
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/remove_workflow_label_when_issue_close.rb

議題指派 QA 成員時自動添加 ~"workflow::in qa"

• 自動化條件：
  • 發生事件：打開、更新、重新打開議題
  • 議題所屬項目為：gitlab-cn/gitlab
  • 議題為開放狀態
  • 議題沒有標記：~"type::qa" （此標記的議題為 QA 單獨的工作，不需要變更工作流）
• 自動化操作：
  • 添加或更新議題的流程標記為：~"workflow::in qa"
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/add_label_when_assigned_to_qa.rb

自動為議題添加 ~"workflow::in dev" 標記

• 自動化條件：
  • 發生事件：更新議題、開啟議題
  • 議題所屬分組為：gitlab-cn
  • 議題為開放狀態
  • 議題沒有添加 workflow 相關標記
  • 議題的作者不是機器人用戶
  • 議題的所有指派人均具有 dev 角色(Backend Engineer/Frontend Engineer)
  • 議題指派人發生了變化
  • 議題沒有 ~"Time tracking" 標記
• 自動化操作：
  • 自動為此議題添加 ~"workflow::in dev" 標記。
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/workflow_in_dev_label_reminder.rb
• 頻率限制：每個議題最多處理一次

流程類

自動為社區類型議題分配 PM

• 自動化條件：
  • 發生事件：創建議題
  • 議題所屬項目為：gitlab-cn/gitlab
  • 議題作者是社區用戶（即該用戶不屬于群組 gitlab-cn）
  • 議題當前分配人里面沒有 PM 角色
• 自動化操作：
  • 給議題添加評論，提醒作者已經為該議題自動分配了一位 PM
  • 給議題隨機分配一位 PM 角色成員
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/assign_pm_for_community_users.rb
• 頻率限制：每個議題處理一次

Bug 類型議題處理

• 自動化條件：
  • 發生事件：創建、更新議題
  • 議題所屬分組為：gitlab-cn
  • 議題所屬分組不為：gitlab-cn/internal
  • 議題為開放狀態
  • 議題添加了標記：~"type::bug"
  • 添加標記 ~"type::bug" 的用戶不為：QA 角色
  • 議題作者不為：QA 角色
  • 議題當前分配人里面沒有 QA 角色
• 自動化操作：
  • 給議題添加評論，提醒當前議題已進入 QA 處理流程
  • 給議題隨機分配一位 QA 角色成員
  • 給議題添加標記：~"workflow::in qa"
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/type_bug_label.rb
• 頻率限制：每個議題處理一次

Feature Flag 被更改類型議題處理

極狐會監控 Upstream Feature Flag 的變動并做出處理，具體見：https://docs.www.happyministry.com/jh/development/workflows/watch_upstream_feature_flag.html

處理人員選取規則：

1. 可選人員在這個文檔中（Roles 包含：Upstream feature flag reviewer）：https://docs.google.com/spreadsheets/d/1HJ5zJLMm5dKxOdk_vhfwrxmJ-QoC4pIJHger8iReuKo
2. 這些狀態會使得你不會被選中
   • Busy indicator is set to True
   • On leave - ?? :palm_tree:, ??? :beach:, ? :beach_umbrella:, ?? :beach_with_umbrella:, ?? :sun_with_face:, ?? :ferris_wheel:
   • Out sick - ??? :thermometer:, ?? :face_with_thermometer:
   • At capacity - ?? :red_circle:
   • Focus mode - ?? :bulb: (focusing on their team’s work)
3. 這些狀態會改變你的選中權重
   • ?? :large_blue_circle: -> 2
   • ?? :large_orange_diamond: -> 0.5
   • ?? :small_orange_diamond: -> 0.2
   • Default -> 1

參考：https://docs.gitlab.com/ee/development/code_review.html#reviewer-roulette

• 自動化條件：
  • 發生事件：創建議題
  • 議題所屬分組為：gitlab-cn
  • 議題為開放狀態
  • 議題添加了標記：~"featureflag::changed"
  • 議題當前分配人里面沒有 Upstream Feature Flag Reviewer 角色
• 自動化操作：
  • 給議題添加評論，提醒當前議題已進入 Feature Flag 審查流程
  • 給議題隨機分配一位 Upstream Feature Flag Reviewer 角色成員
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/featureflag_changed_label.rb

安全審查

MR 被 reviewer approve 后，還需要相關同事從安全的角度進行 review，會自動進入 Triage Ops 安全審查流程，安全審查完成后會打上 ~"security-review::approved" 的標記。

安全審查員選取規則：

1. 可選人員在這個文檔中（Roles 包含：Security reviewer）：https://docs.google.com/spreadsheets/d/1HJ5zJLMm5dKxOdk_vhfwrxmJ-QoC4pIJHger8iReuKo
2. 這些狀態會使得你不會被選中
   • Busy indicator is set to True
   • On leave - ?? :palm_tree:, ??? :beach:, ? :beach_umbrella:, ?? :beach_with_umbrella:, ?? :sun_with_face:, ?? :ferris_wheel:
   • Out sick - ??? :thermometer:, ?? :face_with_thermometer:
   • At capacity - ?? :red_circle:
   • Focus mode - ?? :bulb: (focusing on their team’s work)
3. 這些狀態會改變你的選中權重
   • ?? :large_blue_circle: -> 2
   • ?? :large_orange_diamond: -> 0.5
   • ?? :small_orange_diamond: -> 0.2
   • Default -> 1

參考：https://docs.gitlab.com/ee/development/code_review.html#reviewer-roulette

安全審查準備處理

• 自動化條件：
  • 發生事件：批準合并請求
  • 合并請求所屬項目為：gitlab-cn/gitlab
  • 合并請求為開放狀態
  • 合并請求更新文件不僅僅只有文檔：jh/doc
  • 合并請求沒有安全審查標記：~"security-review::pending", ~"security-review::approved"
  • 合并請求批準人不是安全審查角色
  • 合并請求狀態不為：草稿狀態
• 自動化操作：
  1. 給合并請求創建一個安全審查會話評論（如果不存在）
  2. 隨機選中一名安全審查員
  3. 給合并請求的安全審查會話添加一條評論，通知選中的安全審查員對合并請求做安全審查
  4. 將合并請求的安全審查會話設置為未解決
  5. 給合并請求添加標記：~"security-review::pending"
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/security_review/security_review_ready.rb

安全審查批準處理

• 自動化條件：
  • 發生事件：批準合并請求
  • 合并請求所屬項目為：gitlab-cn/gitlab
  • 合并請求為開放狀態
  • 合并請求更新文件不僅僅只有文檔：jh/doc
  • 合并請求沒有安全審查已批準標記：~"security-review::approved"
  • 合并請求批準人為安全審查角色
  • 合并請求狀態不為：草稿狀態
• 自動化操作：
  1. 給合并請求創建一個安全審查會話評論（如果不存在）
  2. 給合并請求的安全審查會話添加一條評論，描述批準人對當前提交完成了安全審查操作
  3. 將合并請求的安全審查會話設置為已解決
  4. 給合并請求添加標記：~"security-review::approved"
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/security_review/security_review_approve.rb

安全審查批準失效處理

• 自動化條件：
  • 發生事件：更新合并請求
  • 合并請求所屬項目為：gitlab-cn/gitlab
  • 合并請求為開放狀態
  • 合并請求更新文件不僅僅只有文檔：jh/doc
  • 合并請求有安全審查已批準標記：~"security-review::approved"
  • 合并請求有新提交
  • 合并請求狀態不為：草稿狀態
• 自動化操作：
  1. 給合并請求創建一個安全審查會話評論（如果不存在）
  2. 確定一名安全審查員：取最近做了安全審查的用戶，如果沒有就隨機新取一名成員
  3. 給合并請求的安全審查會話添加一條評論，通知選中的安全審查員需要對合并請求重新做安全審查
  4. 將合并請求的安全審查會話設置為未解決
  5. 給合并請求添加標記：~"security-review::pending"
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/security_review/security_review_disapprove.rb

命令類

request_review 命令

• 自動化條件：
  • 合并請求新增一條評論：@jihulab-bot request_review
  • 合并請求所屬分組為：gitlab-cn
  • 合并請求為開放狀態
  • 命令評論作者為合并請求作者本人
• 自動化操作：
  • 根據合并請求信息、團隊成員信息、團隊成員狀態選中一位合適的審查人
    1. 篩選非請求用戶(先排除請求人自己)
    2. 篩選當前項目成員(只選有開發此項目成員，比如 triage-ops 只會篩選出 Dave 和 Song Huang)
    3. 篩選對應前后端的成員(包括經理，前后端標記都存在時選后端，流程上需要后端先處理。依賴 backend/frontend 標記，沒有標記時會停止推薦并提示添加標記)
    4. 篩選成員狀態合適的成員，這里會通過接口請求 GitLab 信息，這里同時要根據 emoji 設置好權重
    5. 優先選對應團隊的成員(優先的意思是非強制，沒有符合規則的就不進行篩選)
    6. 優先選非經理的成員(優先的意思是非強制，沒有符合規則的就不進行篩選)
  • 給合并請求添加一條評論，通知審查人
• 處理器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/triage/processor/command_request_review.rb

成員狀態處理具體規則：

1. 可選人員在這個文檔中：https://docs.google.com/spreadsheets/d/1HJ5zJLMm5dKxOdk_vhfwrxmJ-QoC4pIJHger8iReuKo
2. 這些狀態會使得你不會被選中
   • Busy indicator is set to True
   • On leave - ?? :palm_tree:, ??? :beach:, ? :beach_umbrella:, ?? :beach_with_umbrella:, ?? :sun_with_face:, ?? :ferris_wheel:
   • Out sick - ??? :thermometer:, ?? :face_with_thermometer:
   • At capacity - ?? :red_circle:
   • Focus mode - ?? :bulb: (focusing on their team’s work)
3. 這些狀態會改變你的選中權重
   • ?? :large_blue_circle: -> 2
   • ?? :large_orange_diamond: -> 0.5
   • ?? :small_orange_diamond: -> 0.2
   • Default -> 1

參考：https://docs.gitlab.com/ee/development/code_review.html#reviewer-roulette

周期類自動化操作

“周期類自動化操作” 是機器人 @jihulab-bot 會周期觸發的自動化操作。主要用于處理工作報告和里程碑過渡等問題。

工作報告

里程碑回顧報表

• 報表示例：https://jihulab.com/gitlab-cn/gitlab/-/issues/2009
• 報表內容：
  • 已完成議題列表
  • 未完成議題列表
  • 議題統計信息
  • 合并請求統計信息
  • 流水線統計信息
• 配置器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/policies/stages/hygiene/retrospective-report/create-milestone-retrospective-report-issue.yml
• 周期：北京時間每月 17 號 23 點 同時支持在任何時間手動觸發生成當前里程碑的回顧報表

里程碑過渡

自動為合并請求補全里程碑

• 自動化條件：
  • 處理最近三個月的合并請求
  • 合并請求狀態為：已合并
  • 合并請求沒有設置里程碑
  • 合并請求沒有添加標記：~"milestone fixed"
• 自動化操作：
  • 為所有符合條件的合并請求設置里程碑
    1. 查詢合并請求對應的合并提交
    2. 查詢合并提交的最早進入的版本分支（xxx-stable-jh）
    3. 如果版本分支存在，則取這個版本分支對應的里程碑
    4. 如果版本分支不存在，則查詢當前最大的版本分支，取他對應的下一個里程碑
• 配置器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/policies/stages/hygiene/automatically-add-a-milestone-for-mr.yml
• 周期：北京時間每天 01 點

自動通知發開同事填寫 Capacity Planning

• 自動化條件：
  • 當天為：周五
  • 三天后的周一為：整月里的第一個周一
• 自動化操作：
  • 在 Slack Channel #engineering-internal 里通知 @dev-team 填寫 Capacity Planning
    1. 填寫步驟：http://www.happyministry.com/handbook/engineering/workflow#%E5%85%B3%E4%BA%8E%E5%B7%A5%E4%BD%9C%E9%87%8F%E8%A7%84%E5%88%92
    2. 填寫文檔：https://docs.google.com/spreadsheets/d/1BOawTE1G_GcM9OTqMzxyDDNFiW6qEYJi7cv8hgixsVk
• 配置器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/policies/stages/hygiene/slack/remind-capacity-planning-in-slack.yml
• 周期：北京時間周五 09 點

自動通知開發同事處理 Milestone 遺留任務

• 自動化條件：
  • 12 號執行條件：14 號為周日
  • 13 號執行條件：14 號為周六
  • 14 號執行條件：14 號為工作日
• 自動化操作：
  • 在 Slack Channel #engineering-internal 里通知 @dev-team 處理 Milestone 遺留任務
    1. 根據 team-members 提供的成員信息，查詢每個 Dev 成員在指定里程碑的剩余議題數量
    2. 根據成員剩余議題數量在 Slack 中發送提醒消息
• 配置器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/policies/stages/hygiene/slack/remind-milestone-ending-in-slack.yml
• 周期：北京時間 12、13、14 號 16 點 同時支持在任何時間手動觸發任意里程碑的遺留任務提醒

自動通知開發同事填寫 Milestone 的回顧反饋

• 自動化條件：
  • 當天為：周五
  • 三天后的周一為：整月里的第三個周一
• 自動化操作：
  • 在 Slack Channel #engineering-internal 里通知 @dev-team 填寫 Milestone 的回顧反饋
    1. 填寫文檔：https://docs.google.com/document/d/1KVt4ji5xPmGtNt6Q3rPP_DOlHvT1h68F4lNc6CPBfkM
• 配置器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/policies/stages/hygiene/slack/remind-retrospective-feedback-in-slack.yml
• 周期：北京時間周五 14 點

自動關閉 Time tracking 議題

• 自動化條件：
  • 議題包含標記：~"Time tracking"
• 自動化操作：
  • 關閉議題
• 配置器：https://jihulab.com/gitlab-cn/quality/triage-ops/-/blob/master/policies/stages/hygiene/automatically-close-time-tracking-issues.yml
• 周期：北京時間每月 17 號 18 點

參與貢獻

triage-ops 項目完全開源，歡迎同事們為項目提供產品方面的建議或者提交功能。

• 問題反饋或建議：https://jihulab.com/gitlab-cn/quality/triage-ops/-/issues
• “即時類自動化操作”示例 MR：https://jihulab.com/gitlab-cn/quality/triage-ops/-/merge_requests/14
• “周期類自動化操作”示例 MR：https://jihulab.com/gitlab-cn/quality/triage-ops/-/merge_requests/67