📚 课程目录第4章分支晋级模型

4. 分支晋级模型：从 Feature 到 Production 的晋级路径

分支晋级模型是 GitOps 发布流水线的核心骨架。它定义了代码从开发到上线的完整路径，以及每个阶段必须满足的回归检查条件。在发布窗口场景下，分支晋级不仅是代码合并，更是质量门禁的逐级传递。

4.1 四阶段晋级模型概述

标准 GitOps 分支晋级模型包含四个阶段，每个阶段对应一个长期或短期分支，并绑定特定的环境与检查策略：

阶段	分支名称	目标环境	晋级触发条件	回归检查范围
1	Feature	本地/开发容器	开发者提交 PR	单元测试、代码风格、静态扫描
2	Develop	共享开发环境	PR 合并 + CI 通过	集成测试、API 契约测试
3	Staging	预发布环境	发布窗口开启 + 回归套件通过	端到端测试、性能基线、安全扫描
4	Production	生产环境	发布窗口确认 + 人工审批	金丝雀验证、回滚就绪确认

关键原则：每个晋级步骤都必须是不可逆的——一旦分支从 Develop 合并到 Staging，就不能再直接向 Staging 推送修补，必须重新走 Develop 的回归流程。这保证了发布窗口内的代码基线一致性。

4.2 Feature → Develop：开发集成门禁

这是最频繁的晋级动作，通常每天发生数十次。Feature 分支从 Develop 拉出，开发完成后通过 Pull Request 合并回去。此阶段的核心目标是防止低质量代码污染共享分支。

PR 触发检查：自动运行单元测试（覆盖率 ≥ 80%）、Lint 检查、SonarQube 静态扫描。
线性历史要求：必须执行 Squash Merge 或 Rebase Merge，保持 Develop 分支的提交历史整洁。
冲突阻断：存在合并冲突时，CI 流水线直接标记为失败，不允许合并。
回滚策略：合并后若发现缺陷，通过 Revert Commit 回滚，而非直接在 Develop 上修改。

# 典型 Feature → Develop 合并流程（GitOps 风格）
git checkout develop
git pull origin develop
git checkout -b feature/PAY-1234-fix-timeout
# ... 开发与提交 ...
git push origin feature/PAY-1234-fix-timeout
# 创建 PR，等待 CI 通过 + Code Review
# 合并时使用 squash merge
git checkout develop
git merge --squash feature/PAY-1234-fix-timeout
git commit -m "feat: fix payment timeout (PAY-1234)"
git push origin develop

4.3 Develop → Staging：发布窗口准入

此晋级发生在发布窗口开启时，是回归检查最密集的阶段。Develop 分支的代码必须通过完整的回归套件，才能晋级到 Staging 分支。Staging 分支通常是一个只读的发布候选分支，不允许直接推送。

  发布窗口准入条件（示例）：
  所有集成测试通过（含数据库迁移测试）
API 兼容性检查通过（无破坏性变更）
性能基线对比：P99 延迟增幅 ≤ 5%
安全扫描：无 Critical/High 漏洞
变更日志已更新

晋级操作通常由自动化流水线执行，而非手动合并。流水线会从 Develop 创建标签（如 release/2025-04-15），然后将其合并到 Staging 分支。

# 自动化晋级脚本（伪代码）
if all_regression_checks_passed():
    tag_name = f"release/{datetime.now().strftime('%Y-%m-%d')}"
    create_tag(tag_name, target="develop")
    merge_branch(source="develop", target="staging", tag=tag_name)
    deploy_to_staging_environment()
    notify_team(f"Release {tag_name} promoted to Staging")
else:
    block_promotion()
    notify_failure("Regression checks failed")

4.4 Staging → Production：生产就绪确认

这是最后一道门禁，通常需要人工审批与发布窗口确认。Staging 分支的代码已经在预发布环境验证过，但生产环境仍有额外的检查项。

检查项	描述	通过标准
金丝雀验证	将新版本部署到 5% 的生产实例	运行 15 分钟，错误率 ≤ 0.1%
回滚就绪	确认上一版本镜像仍在仓库中，回滚脚本已验证	回滚脚本 dry-run 通过
发布窗口检查	确认当前时间在允许的发布窗口内	UTC 时间 09:00–15:00，非周末
人工审批	至少 2 名 SRE 或 Tech Lead 批准	审批记录在 Jira/ServiceNow 中

常见陷阱：不要在生产晋级时跳过回归检查，即使 Staging 已经通过。生产环境配置、流量模式、数据规模都与 Staging 不同，必须重新运行关键检查项（尤其是金丝雀和回滚验证）。

4.5 分支晋级流程总览（SVG）

下图展示了从 Feature 分支到 Production 的完整晋级路径，以及每个阶段的关键检查点：

4.6 晋级模型的最佳实践

分支命名规范：Feature 分支使用 feature/<issue-id>-<描述>，Staging 分支使用 release/<日期>，便于自动化脚本识别。
晋级原子性：每个晋级动作必须是原子操作——要么全部成功（合并 + 部署 + 检查），要么全部回滚。
环境一致性：Staging 环境的配置、数据库版本、中间件版本必须与 Production 保持一致，否则回归检查失去意义。
监控联动：晋级成功后，自动更新监控仪表板的版本标签，便于快速定位问题版本。

  发布窗口内的晋级节奏：
  窗口开启前 1 小时：冻结 Develop 分支，禁止新 Feature 合并。
窗口开启时：自动触发 Develop → Staging 晋级。
窗口开启后 30 分钟：Staging 回归套件执行完毕。
窗口开启后 45 分钟：人工审批完成，Staging → Production 晋级。
窗口关闭前 15 分钟：金丝雀验证通过，全量发布完成。

4.7 常见晋级失败场景与处理

失败场景	影响阶段	处理策略
单元测试失败	Feature → Develop	阻止 PR 合并，通知开发者修复
集成测试超时	Develop → Staging	重试一次，若仍失败则标记为阻塞，需人工介入
性能基线下降	Develop → Staging	自动回滚晋级，生成性能对比报告
金丝雀错误率超标	Staging → Production	立即回滚金丝雀，阻塞全量发布
发布窗口超时	Staging → Production	取消本次发布，代码保留在 Staging，等待下一窗口

分支晋级模型不是简单的代码合并，而是质量门禁的逐级传递。每个阶段都承担特定的验证责任，确保只有经过充分验证的代码才能到达生产环境。在发布窗口场景下，晋级节奏必须与窗口时间对齐，避免因检查超时而错过发布窗口。