内部分析审查指南

本页面包含 内部分析 审查的介绍性材料。有关代码审查的更广泛建议和通用最佳实践，请参阅我们的 代码审查指南。

审查流程

当合并请求 (MR) 涉及或使用内部分析代码时，我们必须进行内部分析审查。 这包括但不限于：

• 指标，例如：
  • config/metrics 目录下的文件。
  • ee/config/metrics 目录下的文件。
  • schema.json。
• 内部事件，例如 config/events 目录下的文件。
• 内部分析工具，例如 Internal events CLI。

在大多数情况下，会自动添加内部分析审查，但如果自动化流程遗漏了相关更改，也可以手动请求。

角色与流程

合并请求的 作者 应该

• 判断是否需要进行内部分析审查。如果更改与内部分析领域无关，则可以跳过内部分析审查并移除相应的标签。
• 如果需要进行内部分析审查但未自动分配，请添加标签 ~analytics instrumentation 和 ~analytics instrumentation::review pending。
• 如果合并请求中包含对事件的更改：
  • 使用可用的 测试工具 检查事件是否在本地正常触发。
• 如果合并请求中包含对指标的更改：
  • 通过运行以下命令来确保新指标在 Service Ping 负载中可用并上报数据：require_relative 'spec/support/helpers/service_ping_helpers.rb'; ServicePingHelpers.get_current_usage_metric_value(key_path)，其中 key_path 需替换为新指标的 key_path。
• 使用审查者轮盘来分配一个非作者的内部分析 审查者。
• 根据情况分配其他审查。 ~analytics instrumentation 审查不需要维护者审查。

内部分析的 审查者 应该

• 对合并请求进行初步审查，并向作者提出改进建议。
• 确保没有使用任何已弃用的分析方法。
• 如果审查中包含对事件的更改：
  • 检查触发的事件是否有对应的定义文件。
  • 检查 事件定义文件 是否正确。
  • 检查跟踪参数是否包含任何 敏感信息。
• 如果审查中包含对指标的更改：
  • 为基于数据库的指标添加 ~database 标签，并请求进行 数据库审查。
  • 对于指标的 YAML 定义：
    • 检查指标的 description。
    • 检查指标的 key_path。
    • 检查 product_group 字段。 它们应与 stages 文件 中的对应。
    • 检查文件位置。考虑时间范围，以及文件是否应在 ee 目录下。
    • 检查层级。
  • 如果指标被更改或移除：确保 MR 作者已在 MR 的问题评论中通过 @ 提及客户成功运营团队 (@csops-team)、分析工程师 (@gitlab-data/analytics-engineers) 和产品分析师 (@gitlab-data/product-analysts)，并且所有这些团队都已确认收到通知。
• 如果审查中包含对 Internal Events CLI 的更改：
  • 检查更改是否遵循 CLI 风格指南。
  • 运行 CLI 并检查更改的用户体验：
    • 内容是否易于浏览？
    • 这内容对团队以外的人来说是否有意义？
    • 这信息是否必要？是否有帮助？
    • 如果我从未经历过这个流程，会有什么顾虑？
    • 每个输入的含义或效果是否清晰？
    • 如果我们描述了边缘情况或注意事项，是否有说明来验证用户是否需要担心？
• 批准该 MR，并将 MR 的标签重新标记为 ~"analytics instrumentation::approved"。