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.gitlab.cn/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. 填写步骤：https://gitlab.cn/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