4. 版本控制与分支策略：Git Flow、Trunk-Based Development 对流水线 SLI 的影响

版本控制策略直接决定了 CI/CD 流水线的触发频率、构建深度与回滚路径。不同的分支模型会改变流水线的 部署频率（Deployment Frequency）、变更前置时间（Lead Time for Change） 以及 变更失败率（Change Failure Rate） 等核心 SLI 指标。本章从 Git Flow 与 Trunk-Based Development（TBD）两种主流模型出发，分析其对流水线 SLI 口径的差异化影响。

4.1 分支策略核心维度对比

下表从分支生命周期、集成频率、触发机制三个维度对比两种策略对 SLI 采集的影响：

4.2 Git Flow 对流水线 SLI 的影响

Git Flow 通过多级分支隔离了开发、集成与发布阶段，但同时也引入了 SLI 采集的“盲区”：

• 部署频率（DF）被低估： 由于 release 分支合并到 master 才触发生产部署，而 develop 分支的频繁合并并不直接对应生产变更，导致 DF 指标偏低。
• 变更前置时间（LT）被拉长： 从 feature 分支创建到 master 合并的路径包含多次代码审查、集成测试与 release 冻结期，LT 中位数通常超过 24 小时。
• 变更失败率（CFR）口径模糊： 当 hotfix 分支直接合并到 master 时，该变更是否计入“失败恢复”还是“正常部署”需要明确规则。

4.3 Trunk-Based Development 对流水线 SLI 的影响

TBD 通过短生命周期分支与高频集成，使 SLI 指标更贴近真实交付节奏：

• 部署频率（DF）显著提升： 每次主干合并都可通过自动化流水线直接部署，DF 指标通常达到每日多次。
• 变更前置时间（LT）缩短： 从提交到合并的平均时间通常小于 1 小时，LT 口径更接近“代码提交到生产就绪”的真实延迟。
• 变更失败率（CFR）更敏感： 由于部署频率高，任何一次主干合并失败都会立即反映在 CFR 指标中，要求团队具备快速回滚能力。

4.4 分支策略与流水线 SLI 采集架构

下图展示了两种分支策略下，流水线事件与 SLI 采集点的对应关系：

4.5 分支策略选择对 SLI 口径的工程影响

在实际项目中，分支策略的选择会直接影响 SLI 采集系统的设计：

4.6 分支策略迁移对 SLI 基线的影响

当团队从 Git Flow 迁移到 TBD 时，SLI 基线会发生显著偏移：

• DF 基线可能从“每周 2-3 次”跃升至“每天 10-20 次”，需要重新设定 SLO 目标。
• LT 基线从“小时级”缩短到“分钟级”，原有 LT 告警阈值（如 > 4 小时）将不再适用。
• CFR 基线可能暂时上升，因为高频合并暴露了更多集成问题，但长期会趋于稳定。

4.7 分支策略与流水线安全权限的联动

分支策略还影响流水线的安全权限模型，进而影响 SLI 数据的可信度：

在流水线 SLI 采集系统中，建议将分支策略作为标签（label）附加到每个 SLI 事件上，以便在聚合分析时进行分层对比。例如：

# 流水线事件示例（Git Flow）
{
  "event_type": "deployment",
  "branch": "release/1.2.3",
  "branch_model": "git-flow",
  "timestamp": "2025-03-15T10:30:00Z",
  "status": "success"
}

# 流水线事件示例（TBD）
{
  "event_type": "deployment",
  "branch": "main",
  "branch_model": "trunk-based",
  "feature_flag": "new-checkout-flow",
  "timestamp": "2025-03-15T10:32:00Z",
  "status": "success"
}